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Abstract 


The  Department  of  National  Defence  is  implementing  Capability-Based  Planning  as  a 
core  element  in  the  overall  business  process.  In  this  context,  the  Collaborative 
Capability  Definition,  Engineering,  and  Management  (CapDEM)  Technology 
Demonstration  Project  examine  the  Collaborative  Engineering  concept  to  create  a 
systematic  link  between  the  conceptualization  of  a  capability  and  the  detailed 
definition,  engineering  and  management  of  the  component  systems.  The  current  report 
summarises  the  initial  work  conducted,  from  April  2003  to  December  2003,  by  the 
CapDEM  team  responsible  to  work  out  the  Capability  Engineering  Process  (CEP).  It 
describes  the  main  findings  about  scoping  and  applying  the  future  Canadian  CEP. 

Resume 


Le  ministere  de  la  Defense  nationale  met  en  place  la  planification  axee  sur  les 
capacites  en  tant  qu’ element  central  de  son  processus  global  d'affaires.  Dans  ce 
contexte,  le  projet  de  demonstration  technologique  de  definition,  d’ingenierie  et  de 
gestion  collaboratives  des  capacites  (DIGCap)  examine  le  concept  d’ingenierie 
collaborative  afin  de  creer  un  lien  systematique  entre  la  conceptualisation  d’une 
capacite  et  la  definition  detaillee,  l’ingenierie  et  la  gestion  des  systemes  qui  la 
composent.  Ce  rapport  resume  le  travail  initial  effectue  d'avril  a  decembre  2003  par 
fequipe  de  DIGCap  responsable  de  deflnir  le  processus  d’ingenierie  des  capacites 
(PIC).  II  decrit  les  principaux  resultats  sur  la  portee  et  1’ application  du  futur  PIC 
canadien. 
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Executive  summary 


Background 

The  Department  of  National  Defence  (DND)  is  implementing  Capability-Based 
Planning  (CBP)  as  a  core  element  in  the  overall  business  process.  Currently,  the  CBP 
process  leads  to  the  acquisition  of  systems  within  that  capability.  The  aim  of  the 
Capability  Engineering  (CE)  concept  under  investigation  in  the  Collaborative 
Capability  Definition,  Engineering,  and  Management  (CapDEM)  Technology 
Demonstration  Project  (TDP),  is  to  create  a  systematic  link  between  the 
conceptualization  of  a  capability  and  the  detailed  definition,  engineering  and 
management  of  the  component  systems.  The  main  outcome  of  CE  is  an  improvement 
of  decision-making  for  strategic  investment.  An  analytical  process  or  environment 
needs  to  be  developed  enabling  trade-off  analysis  across  systems  to  evaluate  their 
overall  impact  on  each  other  or  on  the  overall  capability.  This  process,  referred  to  as 
the  Capability  Engineering  Process  (CEP),  must  provide  rigour  and  structure  to 
enhance  synchronization  of  capability  transitioning. 


Figure  1  illustrates  these  relationships,  at  the  conceptual  level,  whereby  the  top  of  the 
figure  indicates  the  current  process  of  “leaping”  from  capability  concept  to  individual 
component  system  acquisition,  and  the  bottom  of  the  figure  proposes  the  introduction 
of  CE  to  provide  rigour  and  structure  to  that  process  so  as  to  enhance  capability 
synchronization  transitioning. 
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Figure  1:  CE  in  the  CBP  Process 

The  application  of  CE  requires  a  process,  supporting  tools,  and  personnel  with  the  skill 
sets  to  employ  this  process  and  tools.  The  best  source  for  processes  and  tools  at  this 
time  is  the  System  Engineering  (SysEng)  domain,  whereby  the  community  has 
standardized  processes  and  are  actively  using  and  enhancing  tools  in  the  area  of 
requirements  management,  functional  modelling,  architecture  modelling,  use  case 
definition,  Computer  Aided  Design  and  Drafting  (CADD),  human  form  and  behaviour 
modelling,  life  cycle  cost  modelling,  and  both  constructive  and  virtual  simulation. 
CapDEM ’s  hypothesis  is  that  these  processes  and  tools,  which  are  normally  applied  on 
a  system  level,  can  be  extended  to  the  capability  (System-of-Systems  -  SoS)  level  to 
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provide  the  basis  for  CE.  As  a  result,  the  baseline  definition  of  CE  at  the  start  of  this 
TD  is: 

“Capability  Engineering  is  the  application  of  system  level  engineering  and 
management  processes  and  tools  to  Capability  Management  in  order  to  establish  the 
necessary  rigour  for  effective  planning,  acquisition  and  evolution  of  a  system-of- 
sy stems  capability”1 

The  CapDEM  TDP  has  been  established  to  define  CE  and  to  validate  the  discipline  in 
the  Canadian  defence  context,  in  collaboration  with  a  wide  range  of  DND  and 
industrial  community  stakeholders.  Figure  2  outlines  the  project  work  plan. 
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Figure  2:  CapDEM  Work  Streams 

Main  findings 

The  current  report  summarises  the  work  conducted  by  the  CEP  Team  from  April  2003 
to  December  2003.  The  objective  of  this  team,  for  the  whole  CapDEM  project,  is  to 
deliver  a  CEP  that  meets  DND/CF’s  needs.  The  development  and  evaluation  of  the 
CEP  will  be  performed  in  three  one-year  cycles  during  the  course  of  the  project. 

The  specific  objective  for  the  first  year  (ending  in  March  2004)  was  to  verify  if  the 
CEP  and  Collaborative  Engineering  Environment  (CEE)  of  the  US  Office  of  the  CHief 
ENGineer  (CHENG)  under  the  Assistant  Secretary  of  the  Navy  for  Research, 
Development,  and  Acquisition  -  also  called  ASN  (RDA)  CHENG  -  are  a  suitable 
starting  point  for  the  project.  The  CEP  Team  used  a  document,  provided  by  Mr. 
Schmidt  through  an  international  team  (TTCP  JSA  TP42)  as  the  CEP  V0  to  be  used  for 


1  CapDEM  Management  Team,  Project  Implementation  Plan  -  Collaborative  Capability  Definition, 
Engineering  and  Management  (CapDEM)  Technical  Demonstration  Project ,  5  May  2003,  49  pp. 

2  TTCP  JSA  TP4  stands  for  “The  Technology  Cooperation  Program  -  Joint  System  and  Analysis  Group 
-  Technical  Panel  4  (Systems  Engineering  for  Defence  Modernization)” 
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case  studies  in  the  first  cycle.  The  specific  objective  for  this  first  cycle  was  to  deliver 

an  integrated  assessment  report  on  the  TP4  CEP  Working  Draft  and  the  tools 

supporting  it. 

From  the  internal  literature  review  on  subjects  relevant  to  CE  and,  analysis  of  the  TP4 

CEP  Working  Draft,  the  following  conclusions  were  drawn: 

•  As  of  December  2003,  the  Canadian  problem  was  not  sufficiently  mastered  by  the 
CEP  Team  to  recommend  or  propose  a  CEP  VI.  The  initial  CapDEM  view  and  the 
TP4  CEP  Working  Draft  provide  good  definitions  of  “process”  and  “CE”  but 
further  investigation  is  required. 

•  In  its  current  overview  version,  the  TP4  CEP  Working  Drafts  not  applicable  by 
itself  since  there  is  insufficient  documentation  available.  Many  elements,  steps  and 
outputs  are  not  clear  enough  to  be  useable.  The  user  has  room  for  a  lot  of 
interpretation,  which  could  lead  to  different  implementations  for  the  same  kind  of 
problem.  Considering  the  limitations  of  the  available  information,  it  is  not  possible 
to  determine  whether  the  resulting  Transformation  Roadmap  would  provide  all 
adequate  information  to  support  strategic  investment  decisions  for  DND/CF 
capability  implementation. 

In  addition,  during  this  first  part  of  Cycle  1,  the  CEP  Team  has  identified: 

•  Possible  scope  of  the  CE  such  as:  aiming  at  evolving  medium-size  family-of- 
systems-based  capability  in  a  few  months  for  a  specific  mission;  or  aiming  at 
creation,  over  a  long  period  of  time  (5  years),  a  dedicated  SoS. 

•  Possible  forms  of  the  process  enabling  the  CE  concept  examined  from  different 
aspects  such  as:  methodology  (Spiral,  Iterative,  Incremental,  Waterfall, 

Custom,. . .),  level  of  refinement  (analysis  of  alternatives  vs  Pugh  Matrix,  1  vs  20 
deliverables,...),  completeness  (What,  When,  Who,  With  What  (tools),  entrance 
criteria,  exit  criteria,  goal  and  reference(s)  for  each  activity,  input  &  output,. . .); 
level  of  adaptability  to  the  organization  (activities  or  deliverables,  generic  or 
tailored  to  an  organization. . .). 

•  Some  candidate  solutions  have  already  been  applied  to  solve  similar  problems  e.g. 
military  acquisition  (Evolutionary  Acquisition,  US  DoD  5000  documents,  CJCSI3 
3170...),  software  engineering  (RUP4,  UML5...),  SysEng  (IEEE  1220,  ISO/IEC6 
12207,  Spiral  Development...),  architecture  description  (DoD  AF,  TOGAF7, 
Zachmann,  Enterprise  Architecture...). 

•  Some  elements  to  be  considered  for  CEP  V 1 : 

•  Be  adaptable  i.e.  specify  deliverables  independent  of  the  utilization 
context  or  tailored  to  the  (Canadian)  organization; 

•  Start  from  standard  approaches  and  well-known  references  such  as 
SysEng,  software  development  and,  enterprise  architecture; 

3  Chairman  of  the  Joint  Chiefs  of  Staff  Instructions 

4  Rational  Unified  Process 

5  Unified  Modeling  Language 

6  Internal  Organization  for  Standardization/International  Electrotechnical  Commission 

7  The  Open  Group’s  Architecture  Framework 
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V 


•  Include  an  effective  usage  of  Modeling  and  Simulation  in  particular,  to 
facilitate  the  reuse  of  data  supporting  it; 

•  Describe  process  activities  with  a  sufficient  level  of  detail;  and 

•  Limit  the  room  for  interpretation  i.e.  be  self-explanatory  and  self- 
contained  (comprehensive). 

Developing  a  CEP:  Main  questions  to  be  answered 

During  our  literature  review  many  questions  were  raised,  many  of  which  address  the 
issues  expressed  above.  Here  are  the  main  ones: 

•  Should  CE  be  able  to  construct  virtual  (short-term  time  frame)  and  dedicated 
(long-term  time  frame)  capabilities? 

•  Should  CEP  be  concerned  with  self-evolution,  joint  evolution  and  emergent 
evolution  (or  any  other  types  of  evolution)  of  a  capability? 

•  Is  CEP  more  related  to  solving  these  managerial  issues  of  concurrent  engineering 
instead  of  traditional  (but  complex)  SysEng  issues? 

•  During  which  phases  of  the  life  cycle  is  CE  applied? 

•  What  are  the  inputs  and  the  outputs  of  CEP  and  who  will  use  this  information? 

•  Should  CEP  be  generic  or  tailored  to  its  context  of  use? 

•  Should  CEP  consider  and  propose  a  solution  composed  of  capability  subelements 
(such  as  DOTMLPF8  or  PRICIE9)  or  be  more  selective  like  the  5000  acquisition 
strategies? 

•  Since  a  capability  can  be  defined  at  various  business  and  technical  levels  of 
granularity,  which  levels  are  optimal  to  reach  the  objectives  of  CEP? 

These  questions  are  not  easy  to  answer  at  this  moment.  A  good  knowledge  of 
requirements  and  “as-is”  architectures  is  essential  to  provide  a  sound  process.  It  will 
contribute  to  the  identification  of  technologies  that  will  form  the  CEP.  It  is  even 
possible  that  the  CEP  itself  will  have  a  different  path  from  one  project  to  another  e.g. 
activities  and  notation  may  differ  depending  on  the  problem  being  solved. 

It  is  probable  that  the  solution  will  be  more  “dedicated”  to  one  (or  a  few)  project(s).  It 
may  be  difficult  to  develop  a  generic  CEP  that  will  address  all  capability  needs  in  the 
future.  The  identification  and  the  understanding  of  technologies  that  may  form  the 
CEP  is  an  important  step  in  every  project.  It  is  also  highly  probable  that  new  expertise 
will  have  to  be  gathered  by  systems  engineers  in  order  to  completely  understand  and 
address  all  inherent  aspects  of  a  proposed  CEP. 

Way  Ahead 

Many  questions  remain  to  be  answered  before  working  out  the  CEP.  Many  of  them 
will  be  answered  when  specific  requirements  of  the  Canadian  capability  development 


8  DoD  acronym  for  Doctrine,  Organizations,  Training,  Materiel,  Leadership,  Personnel  and  Facilities, 

9  DND  acronym  for  Personnel,  R&D/Ops  Research,  Infrastructure  &  Organization,  Concepts,  Doctrine 
&  Collective  Training,  IT  Infrastmcture,  Equipment,  Supplies  and  Services 
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community  and  actual  acquisition  problems  will  be  identified.  Others  will  be  answered 
by  the  CEP  Team  based  on  its  own  experience  and  consultant  resources  and  finally, 
some  will  fall  within  the  competence  of  stakeholders  to  facilitate  institutionalization 
and  resources  prioritization  reasons.  Since  the  problem  space  of  the  CE  is  very  large, 
an  initial  solution  should  tackle  only  a  portion  of  the  problem. 

Based  on  the  knowledge  acquired  during  this  first  nine  months,  the  next  priority  for 
the  CEP  Team  is  to  get  a  very  good  understanding  of  the  current  deficiencies  of  the 
Canadian  process.  As  a  first  step,  the  Canadian  current  situation,  “as-is”,  will  be 
studied,  regarding  mainly  the  current  DND  project  approvals  process.  In  addition, 
other  DND  initiatives  related  to  the  CEP  will  be  examined.  In  parallel,  a  kind  of 
International  current  situation  will  be  worked  out,  looking  at  what  is  being  done 
outside  Canada.  From  these  two  “current  situations”  and  lessons  learned  from  two 
CapDEM  case  studies,  Joint  Intelligence  and  Information  Fusion  Capability  (JIIFC) 
and  Intelligence  Surveillance  and  Reconnaissance  (ISR)  Maritime  the  “to-be”,  CEP 
Version  1,  will  be  elaborated  and  tested  using  subsets  of  these  case  studies. 


Bernier,  F.,  Couture,  M.,  Dussault,  G.,  Lalancette,  C.,  Lam,  S.,  Lemieux,  F.,  Lizotte,  M., 
Mokhtari,  M.  2005.  CapDEM  -  Toward  capability  engineering  process  definition:  A 
discussion  paper:  A  discussion  paper.  DRDC  Valcartier  TR  2004-230.  Defence  R&D 
Canada. 
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Sommaire 


Contexte 

Le  ministere  de  la  Defense  nationale  (MDN)  met  en  place  la  planification  axee  sur  les 
capacites  (PAC)  en  tant  qu’element  central  de  son  processus  global  d’affaires. 
Actuellement,  le  processus  associe  au  PAC  mene  a  l’acquisition  de  systemes  impliques 
dans  la  mise  en  oeuvre  d’une  capacite.  Le  but  du  concept  d’ingenierie  des  capacites 
(IC)  a  1’ etude  dans  le  projet  de  demonstration  technologique  (DT)  intitule  Definition, 
ingenierie  et  gestion  collaboratives  des  capacites  (DIGCap)  est  de  creer  un  lien 
systematique  entre  la  conceptualisation  d’une  capacite  et  la  definition  detaillee, 

1’ ingenierie  et  la  gestion  des  systemes  qui  la  soutiennent.  Le  principal  resultat  du  IC 
est  une  amelioration  de  la  prise  de  decision  pour  l’investissement  strategique.  Un 
processus  analytique  ou  un  environnement  doit  etre  developpe  pour  permettre 
Panalyse  comparative  parmi  des  systemes  afin  d’evaluer  leur  impact  mutuel  ou  leur 
impact  sur  la  capacite  globale.  Ce  processus,  designe  sous  le  nom  de  processus 
d’ingenierie  des  capacites  (PIC),  doit  fournir  la  rigueur  et  la  structure  pour  ameliorer  la 
synchronisation  de  la  transition  vers  la  capacite. 

La  Figure  3  illustre  ces  relations  au  niveau  conceptuel.  Le  haut  de  la  figure  presente  le 
processus  actuel  qui  passe  directement  du  concept  de  capacite  a  l’acquisition  de 
composantes  individuelles  de  systemes,  tandis  que  le  bas  de  la  figure  propose 
1’ introduction  du  IC  pour  fournir  la  rigueur  et  la  structure  a  ce  processus  afin 
d’ ameliorer  la  synchronisation  de  la  transition  vers  la  capacite. 


Planification  axee 
sur  les  capacites 


Acquisition 
de  systeme(s)  ou 
de  plate-forme(s) 


Propose 


Ingenierie  des 
capacites 


Figure  3  :  Le  IC  dans  le  processus  du  PAC 

L’application  du  IC  exige  un  processus,  des  outils  de  support  et  le  personnel  avec  les 
competences  pour  les  utiliser.  Actuellement,  la  meilleure  source  pour  puiser  des 
processus  et  des  outils  est  le  domaine  de  1’ ingenierie  des  systemes  (IngSys).  La 
communaute  associee  possede  des  processus  normalises,  utilise  et  ameliore  activement 
des  outils  dans  le  secteur  de  la  gestion  des  besoins,  la  modelisation  fonctionnelle,  la 
modelisation  d’ architecture,  la  definition  de  cas  d’utilisation,  la  conception  assistee  par 
ordinateur  (CAO),  la  modelisation  comportementale  et  les  facteurs  humains,  la 
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modelisation  du  cout  du  cycle  de  vie  et  les  simulations  virtuelles  autant  que 
constructive.  L’hypothese  de  DIGCap  est  que  ces  processus  et  outils,  qui  sont 
normalement  appliques  au  niveau  d’un  systeme,  peuvent  etre  etendus  au  niveau  d’une 
capacite  (Systeme  de  systemes  -  SdS)  pour  foumir  la  base  pour  le  IC.  Par  consequent, 
la  definition  de  base  du  IC  au  debut  de  ce  projet  est 

«L’ingenierie  des  capacites  est  1’ application  de  l’ingenierie  au  niveau  systeme,  de  la 
gestion  de  processus  et  d’ outils  a  la  gestion  de  capacites  afin  d’etablir  la  rigueur 
necessaire  pour  la  planification,  l’acquisition  et  revolution  efficaces  des  capacites 
derivees  de  systemes  de  systemes  »10 

Le  projet  DIGCap  a  ete  etabli  pour  definir  le  IC  et  pour  valider  la  discipline  dans  le 
contexte  canadien  de  la  defense,  en  collaboration  avec  un  eventail  de  parties  prenantes 
du  MDN  et  de  l’industrie.  La  Figure  4  decrit  le  plan  de  travail  du  projet. 

2002  2003  2004  2005  2006  2007 


Def.  du  projet 

Gestion  du  projet 


Figure  4:  Plan  de  travail  de  DIGCap 

Principales  conclusions 

Ce  rapport  resume  le  travail  effectue  par  l’equipe  du  PIC  d’avril  a  decembre  2003. 
L’objectif  de  l’equipe,  pour  le  projet  DIGCap  au  complet,  est  de  livrer  un  PIC  qui 
satisfait  les  besoins  du  MDN  et  des  Forces  canadiennes  (FC).  Le  developpement  et 
revaluation  du  PIC  seront  executes  en  trois  cycles  d’une  annee  chacun. 

L’objectif  speciflque  de  la  premiere  annee  (finissant  en  mars  2004)  etait  de  verifier  si 
le  PIC  et  l’environnement  collaboratif  d’ingenierie  (ECI)  du  Bureau  americain  de 
l’lngenieur  en  chef  (CHENG)  place  sous  le  secretaire  auxiliaire  de  la  Marine  pour  la 
Recherche,  le  developpement  et  1’ acquisition  -  egalement  appele  ASN  (RDA) 


10  CapDEM  Management  Team,  Project  Implementation  Plan  -  Collaborative  Capability  Definition, 
Engineering  and  Management  (CapDEM)  Technical  Demonstration  Project ,  5  May  2003,  49  pp. 
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CHENG  -  sont  un  point  de  depart  approprie  pour  DIGCap.  L’equipe  du  PIC  a  utilise, 
comme  version  initiale  du  PIC  (PIC  VO),  un  document  ecrit  par  M.  Schmidt  pour  les 
besoins  d’une  equipe  internationale  (TTCP  JSA  TP411)  et  l’a  employe  pour  les  etudes 
de  cas  du  cycle  1.  L’objectif  specifique  de  ce  premier  cycle  etait  de  livrer  un  rapport 
d’ evaluation  integree  de  Pebauche  PIC  de  TP4  et  des  outils  le  supportant. 

De  la  revue  interne  de  litterature  sur  des  sujets  concemant  le  IC  et  1’ analyse  de 
Pebauche  PIC  de  TP4,  les  conclusions  suivantes  ont  ete  tirees  : 

•  En  date  de  decembre  2003,  le  probleme  canadien  n’a  pas  ete  suffisamment 
maitrise  par  Pequipe  du  PIC  pour  recommander  ou  proposer  un  PIC  VI.  La  vue 
initiale  de  DIGCap  et  Pebauche  PIC  de  TP4  fournissent  de  bonnes  definitions  du 
«  processus  »  et  du  «  IC  »,  mais  des  recherches  supplementaires  sont  necessaires. 

•  Dans  sa  version  actuelle,  Pebauche  du  PIC  de  TP4  est  non  applicable,  puisque  la 
documentation  disponible  est  insuffisante.  Beaucoup  d’elements,  etapes  et  sorties 
ne  sont  pas  assez  clairs  pour  etre  utilisables.  Trop  de  place  est  laissee  a 

P interpretation  de  Putilisateur,  ce  qui  pourrait  mener  a  differentes  realisations  pour 
le  meme  genre  de  probleme.  Etant  donne  les  limitations  de  Pinformation 
disponible,  il  n’est  pas  possible  de  determiner  si  la  carte  de  transformation 
resultante  foumit  toutes  les  informations  pertinentes  pour  soutenir  les  decisions 
strategiques  d’investissement  pour  Pimplantation  des  capacites  du  MDN/FC. 

De  plus,  durant  le  cycle  1,  Pequipe  du  PIC  a  identifie: 

•  La  portee  possible  du  IC:  viser  P evolution,  sur  une  periode  de  quelques  mois, 
d’une  capacite  basee  sur  une  famille  de  systemes  de  taille  moyenne,  pour  une 
mission  specifique  ou  viser  la  creation,  sur  une  longue  periode  de  temps  (5  ans), 
d’un  SdS  dedie. 

•  Les  formes  possibles  du  processus  permettant  le  concept  du  IC  examine  sous 
differents  aspects:  methodologie  (spirale,  iterative,  incrementale,  cascade, 
personnalisee...),  niveau  de  raffinement  (analyse  des  solutions  de  rechange  versus 
matrice  de  Pugh,  1  livrable  versus  20...),  completude  (quoi,  quand,  qui,  avec  quoi 
(outils),  criteres  d’entree,  criteres  de  sortie,  but  et  reference(s)  pour  chaque 
activite,  entree  et  sortie...);  niveau  d’ adaptability  a  l’organisation  (activites  ou 
livrables,  generique  ou  congu  en  fonction  d’une  organisation...). 

•  Quelques  solutions  candidates  deja  appliquees  pour  resoudre  des  problemes 
semblables  :  l’acquisition  militaire  (acquisition  evolutive,  documents  5000  du  US 
DoD,  CJCSI12  3170...),  l’ingenierie  logicielle  (RUP13,  UML14...),  IngSyS  (IEEE 
1220,  ISO/IEC15  12207,  developpement  en  spirale...),  la  description  d’ architecture 
(DoD  AF,  TOGAF16,  Zachmann,  architecture  d’entreprise...). 

•  Quelques  elements  dont  il  faut  tenir  compte  pour  le  PIC  V 1 : 


11  TTCP  JSA  TP4  -  “The  Technology  Cooperation  Program  -  Joint  System  and  Analysis  Group  - 
Technical  Panel  4  (Systems  Engineering  for  Defence  Modernization)” 

12  Chairman  of  the  Joint  Chiefs  of  Staff  Instructions 

13  Rational  Unified  Process 

14  Unified  Modeling  Language 

15  Internal  Organization  for  Standardization/International  Electrotechnical  Commission 

16  The  Open  Group’s  Architecture  Framework 
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•  Etre  adaptable  c.-a-d.  specifier  des  livrables  independants  du  contexte 
d’utilisation  ou  congus  en  fonction  de  l’organisation  (canadienne); 

•  Debuter  par  des  approches  standard  et  des  references  bien  connues,  telles 
que  IngSys,  l’ingenierie  logicielle  et  l’architecture  d’entreprise; 

•  Inclure  une  utilisation  efficace  de  la  modelisation  et  de  la  simulation, 
pour  faciliter  la  reutilisation  des  donnees  le  supportant; 

•  Decrire  les  activites  du  processus  avec  un  niveau  suffisant  de  detail;  et 

•  Limiter  la  place  a  1’ interpretation  c.-a-d.  etre  explicite  et  comprehensible. 


Developper  un  PIC:  Principales  questions  qui  necessitent  une  reponse 


Pendant  notre  revue  de  litterature,  beaucoup  de  questions  ont  ete  soulevees,  plusieurs 
abordent  les  problemes  presentes  precedemment.  Les  principales  questions  sont 
enumerees  ici: 


•  Le  IC  devrait-il  permettre  de  construire  des  capacites  virtuelles  (existence  de 
courte  duree)  autant  que  dediees  (existence  de  longue  duree)? 

•  Le  PIC  devrait-il  etre  concerne  par  1’ auto-evolution,  P evolution  jointe  et 
revolution  emergente  (ou  n’importe  quel  autre  type  devolution)  d’une  capacite? 

•  Le  PIC  est-il  plus  lie  a  la  resolution  de  problemes  de  gestion  de  l’ingenierie 
concurrente  au  lieu  de  problemes  de  1’ IngSys  traditionnelle  (mais  complexe)? 

•  Pendant  quelles  phases  du  cycle  de  vie  s’ applique  le  IC? 

•  Quels  sont  les  intrants  et  les  extrants  du  PIC  et  qui  utilisera  1’ information? 

•  Le  PIC  devrait-il  etre  generique  ou  personnalise  a  son  contexte  d’utilisation? 

•  Le  PIC  devrait-il  envisager  et  proposer  une  solution  composee  de  sous  elements 
d’une  capacite  (tels  que  DOTMLPL17  ou  PRICIE18)  ou  etre  plus  selectif  comme 
dans  les  strategies  5000  d’ acquisition? 

•  Puisqu’une  capacite  peut  etre  definie  a  differents  niveaux  -  technologique  et 
commercial  -  de  granularite,  quels  niveaux  sont  optimaux  pour  atteindre  les 
objectifs  du  PIC? 

II  n’est  pas  facile  de  repondre  a  ces  questions  au  point  ou  nous  en  sommes 
actuellement.  Une  bonne  connaissance  des  besoins  et  des  architectures  actuelles  est 
essentielle  pour  fournir  un  processus  solide.  Elle  contribuera  a  1’ identification  des 
technologies  qui  formeront  le  PIC.  II  est  possible  que  le  PIC  lui-meme  ait  un  parcours 
different  d’un  projet  a  l’autre.  Par  exemple,  activites  et  notation  peuvent  differer  selon 
le  probleme  a  resoudre. 

II  est  probable  que  la  solution  sera  davantage  dediee  a  un  ou  des  projet(s).  II  peut  etre 
difficile  de  developper  un  PIC  generique  qui  satisfera,  dans  l’avenir,  tous  les  besoins 
en  capacite.  L’ identification  et  la  comprehension  des  technologies  qui  peuvent  former 


17  Acronyme  du  departement  de  la  Defense  -  Etats-Unis  pour  Doctrine,  Organizations,  Training, 
Materiel,  Leadership,  Personnel  and  Facilities, 

18  Acronyme  du  MDN  pour  Personnel,  R&D/Ops  Research,  Infrastructure  &  Organization,  Concepts, 
Doctrine  &  Collective  Training,  IT  Infrastmcture,  Equipment,  Supplies  and  Services 
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le  PIC  sont  des  etapes  importantes  dans  chaque  projet.  II  est,  de  plus,  fortement 
probable  que  la  nouvelle  expertise  devra  etre  recueillie  par  des  ingenieurs  de  systemes 
afln  de  comprendre  et  adresser  dans  sa  globalite  tous  les  aspects  inherents  a  un  PIC 
propose. 

Travaux  futurs 

Plusieurs  questions  restent  en  suspens  avant  d’etablir  le  PIC.  Bon  nombre  d’entre  elles 
trouveront  une  reponse  lorsque  les  besoins  specifiques  de  la  communaute  canadienne 
de  developpement  de  capacites  et  les  problemes  reels  d’acquisition  seront  identifies. 
Certaines  reponses  proviendront  de  l’equipe  du  PIC  qui  se  basera  sur  sa  propre 
experience  et  sur  les  ressources  de  conseillers.  Finalement,  d’autres  viendront  des 
competences  des  parties  prenantes  a  faciliter  l’institutionnalisation  et  la  priorisation 
des  ressources.  Puisque  la  portee  du  probleme  du  IC  est  tres  vaste,  une  premiere 
solution  devrait  aborder  seulement  une  partie  du  probleme. 

Basee  sur  la  connaissance  acquise  pendant  ces  neuf  premiers  mois,  la  prochaine 
priorite  pour  l’equipe  du  PIC  est  d’obtenir  une  tres  bonne  connaissance  des  manques 
actuels  du  processus  canadien.  Dans  un  premier  temps,  la  situation  presente 
canadienne  «  reelle  »  sera  etudiee,  en  tenant  compte  principalement  du  processus 
actuel  d’ approbation  des  projets  au  sein  du  MDN.  En  plus,  d’autres  initiatives  du 
MDN  liees  au  PIC  seront  examinees.  En  parallele,  une  sorte  de  situation  actuelle 
intemationale  sera  etablie,  regardant  ce  qui  est  fait  a  l’exterieur  du  Canada.  De  ces 
deux  «  situations  actuelles  »  et  des  legons  apprises  de  deux  etudes  de  cas  de  DIGCap 
intitulees,  Intelligence  et  capacites  communes  de  fusion  de  1’ information  (ICCFI)  et 
Intelligence,  surveillance  et  reconnaissance  (ISR)  maritime,  PIC  VI  sera  elabore  et 
teste  en  utilisant  des  sous-ensembles  de  ces  etudes  de  cas. 


Bernier,  F.,  Couture,  M.,  Dussault,  G.,  Lalancette,  C.,  Lam,  S.,  Lemieux,  F.,  Lizotte,  M., 
Mokhtari,  M.  2005.  CapDEM  -  Toward  capability  engineering  process  definition:  A 
discussion  paper.  DRDC  Valcartier  TR  2004-230.  R  et  D  pour  la  defense  Canada. 
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1.  Introduction 


The  Department  of  National  Defence  (DND)  is  currently  implementing  Capability 
Based  Planning  (CBP)  as  a  core  element  in  its  overall  business  process.  Once  defined 
by  the  CBP,  a  capability  must  be  managed  and  more  particularly  engineered.  The 
Collaborative  Capability  Definition,  Engineering,  and  Management  (CapDEM) 
Technology  Demonstration  Project  (TDP)  aims  at  defining  Capability  Engineering 
(CE)  and  validating  the  discipline  in  the  Canadian  defence  context,  in  collaboration 
with  a  wide  range  of  DND  and  industrial  community  stakeholders.  An  important  part 
of  this  project  consists  of  defining  and  refining  a  Capability  Engineering  Process 
(CEP)  meeting  DND/CF’s  needs.  As  with  many  other  work  streams  in  this  TD,  the 
development  and  evaluation  of  the  CEP  will  be  performed  in  three  one-year  cycles 
during  the  course  of  the  project. 

The  report  summarises  the  work  conducted  by  the  CEP  Team  from  April  2003  to 
December  2003.  The  specific  objective  for  the  first  year  (ending  in  March  2004)  was 
to  verify  if  the  CEP  and  Collaborative  Engineering  Environment  (CEE)  of  the  US 
Office  of  the  CHief  ENGineer  (CHENG)  under  the  Assistant  Secretary  of  the  Navy  for 
Research,  Development,  and  Acquisition  -  also  called  ASN  (RDA)  CHENG  -  are  a 
suitable  starting  point  for  the  project. 

Section  2  introduces  CE,  a  key  concept  under  investigation  within  CapDEM  TDP.  CE 
aims  at  improving  decision-making  for  strategic  investment  through  an  analytical 
process  or  environment.  Trade-off  analysis  can  be  conducted  across  systems  to 
evaluate  their  overall  impact  on  each  other  or  on  the  overall  capability  needs  to  be 
developed.  This  process  referred  as  the  CEP  should  provide  rigour  and  structure  to 
enhance  capability  synchronization  transitioning.  In  addition,  Section  2  summarises 
the  CEP  Team  mandate  and  its  execution  from  April  2003  to  December  2003.  The 
team  has  structured  its  effort  around  the  ASN  (RDA)  CHENG  approach  that  was 
considered  to  be  a  suitable  starting  point  for  the  Canadian  investigations.  The  main 
activities,  events  and  decision  points  are  presented  in  chronological  order. 

Section  3  presents  several  perspectives  of  the  CE  (CEP)  reflecting  the  evolution  in 
understanding  by  CEP  Team  of  what  is  or  what  would  be  CE  (CEP).  CE  is  a  new 
concept  within  DND  and  the  understanding  that  people  have  of  it  is  currently  limited. 
Each  perspective  is  presented  according  to  some  aspects  such  as  possible  scopes  and 
specific  objectives,  candidate  solutions  and  process  forms.  A  first  perspective  is  given 
by  CapDEM  TDP  documents  [9]  [12],  which  propose  many  candidate  solutions  as  part 
of  the  CEP.  Instead  of  opting  for  the  development  of  a  completely  novel  CEP  of  its 
own,  DRDC  decided  to  build  on  an  existing  construct  by  evaluating  the  efforts  of  an 
international  team  (TTCP  JSA  TP419).  This  second  perspective  is  referred  in  this  report 
as  TP4  CEP  Working  Draft  and  is  described  in  the  document  entitled  “Overview  of  the 
Capability  Engineering  Process”  produced  in  June  2003  [75].  The  third  part  of  Section 
3  is  dedicated  to  the  review  of  technologies  which  could  complete  the  two  previously 


19  TTCP  JSA  TP4  stands  for  “The  Technology  Cooperation  Program  -  Joint  System  and  Analysis 
Group  -  Technical  Panel  4  (Systems  Engineering  for  Defence  Modernization)” 
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perspectives.  Finally,  the  last  part  of  Section  3  synthesizes  information  and  presents  an 
integrated  version  of  all  presented  perspectives. 

Section  4  presents  an  analysis  of  the  TP4  CEP  Working  Draft.  The  analysis  is  based  on 
two  independent  theoretical  efforts:  an  internal  DRDC  effort  conducted  by  defence 
scientists  and  a  parallel  one  conducted  by  contracted  consultants.  The  analysis  is 
divided  into  four  aspects:  strengths,  limitations,  qualitative  assessment  and 
applicability.  The  presented  strengths  are  rather  high-level  observations  while  the 
limitations  are  more  specific  observations.  This  analysis  summarises,  as  of  December 
2003,  the  thoughts  of  the  CEP  Team  about  the  TP4  CEP  Working  Draft  based  on 
available  (documented)  details  at  that  time.  The  section  ends  by  a  conclusion  of  the 
applicability  of  TP4  CEP  Working  Draft  for  use  by  DND. 

Section  5  describes  the  application  of  the  TP4  CEP  Working  Draft  using  the  Joint 
Intelligence  and  Information  Fusion  Capability  (JIIFC)  as  a  use  case.  The  goal  of  the 
use  case  study  was  to  gain  practical  experience  on  the  TP4  CEP  Working  Draft.  This 
case  study  allowed  the  CEP  Team  to  evaluate  the  TP4  CEP  Working  Draft  from  a 
practical  perspective  through  “hands-on”  experience.  Section  5  captures  lessons- 
learned  on  the  analysis  and  adaptation  of  the  process  and  on  the  application  of  the  CEE 
to  support  JIIFC  concept  definition  activities.  As  a  CapDEM  activity,  the  scope  of  this 
use  case  study  focused  mainly  on  the  application  and  analysis  of  the  TP4  CEP 
Working  Draft  and  the  CEE.  Nonetheless,  the  CEP  Team  worked  closely  with  JIIFC 
project  team  to  ensure  the  work  being  carried  out  met  the  requirements  of  both  the 
CapDEM  and  JIIFC  projects. 

Finally,  the  report  concludes  by  evoking  important  points  to  retain  and  introduces 
some  thoughts  on  the  way  ahead. 
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2.  Background 


CE  is  a  key  concept  under  investigation  within  the  CapDEM  TDP;  it  aims  at 
improving  decision-making  for  strategic  investment.  The  CEP  Team  has  the  mandate 
to  explore  such  a  process  to  assess  its  viability  at  meeting  DND/CF’s  requirements.  As 
a  first  phase  in  the  execution  of  this  mandate,  the  team  has  structured  its  effort  around 
examining  the  RDA  CHENG  approach.  The  following  sections: 

•  Introduce  the  concept; 

•  Describe  the  CEP  Team  mandate;  and 

•  Summarise  its  execution  until  December  2003. 

2.1  The  CE  Concept 

The  DND  is  currently  implementing  CBP  as  a  core  element  in  the  overall  business 
process.  Once  a  capability  is  defined  it  must  then  be  managed.  Capability  Management 
considers  a  number  of  sub-domains  including  Capability  Development  and 
Improvement,  Capability  Employment  and  Operation,  and  Capability  Sustainment.  CE 
is  primarily  focused  on  the  development  and  improvement  domain  as  illustrated  in 
Figure  5. 


Figure  5:  CE  is  One  Domain  of  Capability  Management  (from  [12]) 


Currently  in  DND  the  CBP  process  leads  to  the  acquisition  of  systems  within  that 
capability.  However,  there  is  not  a  systematic  link  between  the  conceptualization  of  a 
capability  and  the  detailed  definition  of  the  component  systems,  nor  is  there  an 
analytical  process  or  environment  where  trade-off  analysis  can  be  conducted  across 
systems  to  evaluate  their  overall  impact  on  each  other  or  on  the  overall  capability.  In 
order  to  “systematize”  this  capability  development  process  the  rigour  of  the  System 
Engineering  (SysEng)  process  is  required.  Figure  6  illustrates  these  relationships  at  the 
conceptual  level,  whereby  the  top  of  the  figure  indicates  the  current  process  of 
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“leaping”  from  capability  concept  to  individual  component  system  acquisition,  and  the 
bottom  of  the  figure  proposes  the  introduction  of  a  CEP  to  provide  rigour  and  structure 
to  that  process  so  as  to  enhance  capability  synchronization  transitioning. 


Capability- 
Based  Planning 


Platform/System 

Acquisition 


Proposed 


Figure  6:  CE  in  the  CBP  Process  (from  [12]) 


The  application  of  CE  requires  a  process,  supporting  tools,  and  personnel  with  the  skill 
sets  to  employ  this  process  and  tools.  The  best  source  for  processes  and  tools  at  this 
time  is  the  SysEng  domain,  whereby  the  community  has  standardized  processes  and 
are  actively  using  and  enhancing  tools  in  the  area  of  requirements  management, 
functional  modelling,  architecture  modelling,  use  case  definition,  Computer  Aided 
Design  and  Drafting  (CADD),  human  form  and  behaviour  modelling,  life  cycle  cost 
modelling,  and  both  constructive  and  virtual  simulation.  CapDEM’s  hypothesis  is  that 
these  processes  and  tools,  which  are  normally  applied  on  a  system  level,  can  be 
extended  to  the  capability  (System-qf-Systems  -  SoS)  level  to  provide  the  basis  for  CE. 
As  a  result,  the  baseline  definition  of  CE  at  the  start  of  this  TD  is: 

“Capability  Engineering  is  the  application  of  system  level  engineering  and 
management  processes  and  tools  to  Capability  Management  in  order  to  establish  the 
necessary  rigour  for  effective  planning,  acquisition  and  evolution  of  a  system-of- 
systems  capability”20 

The  CapDEM  TDP  has  been  established  to  define  CE  and  to  validate  the  discipline  in 
the  Canadian  defence  context,  in  collaboration  with  a  wide  range  of  DND  and 
industrial  community  stakeholders.  Figure  7  outlines  the  project  work  plan. 


20 


[12]  p.  3 
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Figure  7:  CapDEM  Work  Streams  as  of  December  2003 

2.2  Mandate 

The  current  report  summarises  the  work  conducted  by  the  CEP  Team  from  April  2003 
to  December  2003.  The  objective  of  this  team,  for  the  whole  CapDEM  project,  is  to 
deliver  a  CEP  that  meets  DND/CF’s  needs.  As  with  many  other  work  streams  in  this 
TD,  the  development  and  evaluation  of  the  CEP  will  be  performed  in  three  one-year 
cycles  during  the  course  of  the  project. 

The  initial  CEP  plan  for  the  first  cycle  (April  2003 -March  2004)  is  based  on  the 
following  assumption,  described  in  the  CapDEM  Project  Implementation  Plan  (PIP) 
[12]:  The  approach  of  the  US  ASN  (RE)  A)  CHENG  is  a  suitable  starting  point  for  the 
Canadian  investigations,  and  these  tools  will  be  straight  forward  to  install  and  integrate 
on  DRDC/DND  information  networks.  The  CEP  Team  considered  this  approach  as  the 
CEP  V0  to  be  used  for  case  studies  in  the  first  cycle.  The  specific  objective  for  this 
first  year  is  to  deliver  an  integrated  assessment  report  about  this  approach. 

The  following  subsections  describe  the  execution  of  this  mandate  by  summarising  the 
main  activities,  events  and  decision  points. 

2.2.1  Training  on  SysEng  and  ASN  (RDA)  CHENG  Tools 

As  planned,  the  project  started  in  April  2003.  Two  customised  training 
courses  on  SysEng  were  given,  a  first  one  by  Dr  Denis  Laurendeau  [57],  a 
professor  of  Laval  University  and  a  second  by  Mr  Richard  Schmidt  [76]  from 
Systems  Technology,  Inc.,  a  consultant  under  contract  by  RDA  CHENG.  In 
addition,  some  team  members  attended  the  INCOSE  2003  conference  [71]. 
Many  members  also  had  training  on  the  main  tools  used  by  RDA  CHENG 
approach  i.e.  DOORS  by  Telelogic  [78],  CORE  by  Vitech  Corporation  [85], 
and  Interchange  by  Trident  Systems  Inc  [80]. 
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2.2.2  Training  on  the  ASN  (RDA)  CHENG  approach 

The  CEP  mandate  being  to  evaluate  the  ASN  (RDA)  CHENG  approach  and 
supporting  tools,  the  most  important  training  course  was  given  to  CEP  Team 
members  by  Mr.  Richard  Schmidt,  a  senior  systems  engineer  consultant  who 
is  intimately  familiar  with  the  ASN  (RDA)  CHENG  approach,  who  defined 
the  key  process  and  toolsets.  The  course  brought  a  good  opportunity  to  have 
interesting  exchanges  about  SysEng;  it  was  very  useful  for  the  CEP  Team  at 
this  stage  but  lack  details  about  how  to  apply  the  ASN  (RDA)  CHENG 
approach. 

From  previous  discussions  and  presentations,  it  was  known  that  this  approach 
was  based  on  Department  of  Defence  Architecture  Framework  (DoD  AF) 
[28][29][30]  (formerly  C4ISR  AF)  and  IEEE  1220  [44].  Following 
discussions  with  Mr.  Schmidt,  the  team  understood  that  US  Defence  industry 
has  asked  DoD  to  stop  mandating  a  process  in  the  Request  For  Proposals 
(RFPs);  DoD  did  so.  Now  instead  of  imposing  a  specific  process,  DoD 
requires  specific  deliverables  specified  in  DoD  AF  and  leaves  industry  to 
decide  for  itself,  which  specific  systems  engineering  processes  will  be  used  to 
produce  them  most  effectively.  There  is  also  no  notation  mandated  within 
DoD  AF  but  they  are  giving  guidelines  on  Unified  Modeling  Language 
(UML)  usages  [74] [81]. 

Following  this  training,  Mr.  Schmidt  provided  to  the  CEP  Team  a  document 
entitled  “Overview  of  the  Capability  Engineering  Process”  in  June  2003  [75] 
through  the  TTCP  JSA  TP4.  This  document  was  the  most  relevant  document 
available  to  examine  the  ASN  (RDA)  CHENG  approach.  This  document  is 
referred  in  this  report  as  TP4  CEP  Working  Draft. 

2.2.3  Practical  Analysis  with  JIIFC 

The  CEP  Team  started  by  using  the  TP4  CEP  Working  Draft,  the  IEEE  1220 
and  DoD  AF  to  validate  the  CEP  with  the  JIIFC  case  study.  This 
experimentation  allowed  the  team  to  evaluate  the  first  activity  of  TP4  CEP 
Working  Draft  proposal,  the  “as-is”  architecture  of  JIIFC,  from  a  practical 
perspective  [22].  Lessons-learned  through  this  “hands-on”  experience  were 
collected  on  the  analysis  and  adaptation  of  the  process  as  well  as  on  the 
application  of  the  RDA  CHENG  tools. 

2.2.4  Literature  Study 

In  order  to  learn  about  the  subject  under  study  and  in  addition  to  the  training, 
the  CEP  Team  conducted  a  literature  study  covering  SoS,  SysEng  standards, 
Simulation-Based  Acquisition  (SB A)  and  US  acquisition.  This  study  was 
performed  in  two  phases  separated  by  a  workshop  investigating  the  TP4  CEP 
Working  Draft.  The  workshop  raised  some  new  elements  to  investigate. 

2.2.5  Theoretical  Analysis 

The  CEP  Team  conduct  a  theoretical  analysis  of  the  TP4  CEP  Working  Draft. 
Two  independent  assessments  were  conducted  to  get  different  viewpoints.  A 
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consultant,  Mr  Jocelyn  Leclerc  from  CGI,  was  asked  to  examine  the  process 
based  on  his  industrial  experience  and  theoretical  knowledge  [58].  In 
addition,  the  CEP  Team  held  a  workshop21  to  make  its  own  viewpoint  on  the 
process.  After  this  analysis,  R.  Schmidt  was  invited  to  clarify  some  elements 
in  order  to  complete  the  theoretical  analysis  (see  Annexe  B). 


21  This  two-days  workshop  was  held  at  DRDC  Valcartier  in  September  2003  (1 1-12  sept.). 
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3.  Perspectives on the C  E  P 


The  CE  construct  is  a  new  concept  that  aims  at  setting  up  and  improving  military 
capabilities  in  the  CF.  Reaching  this  final  objective  implies  improving  actual 
capability  acquisition  approaches  that  suffer  from  a  number  of  inefficiencies.  The 
underlying  problems  of  the  actual  acquisition  approach  must  be  solved.  However,  the 
CE  concept  cannot  improve  every  aspect  or  solve  all  underlying  problems  related  to 
capability  acquisition.  Investigations  showed  that  opportunities  to  improve  capabilities 
are  numerous.  Consequently,  the  scope  of  intervention  of  the  CE  must  be  identified 
first,  and  then  a  solution  must  be  proposed  to  solve  a  specific  problem  corresponding 
to  portion  of  the  scope.  This  choice  will  then  define  specific  objectives  of  the  CEP  and 
not  only  its  final  objective. 

At  the  beginning  of  the  project,  there  was  a  unique  perspective  of  the  CEP.  This 
perspective  was  described  in  the  CapDEM  TDP  documents  [9]  [12]  and  technologies 
referred  by  these  documents.  An  initial  understanding  of  CEP  has  been  built  on  this 
perspective.  At  the  time  of  writing  this  document,  the  possibilities  for  CEP  are  still 
numerous.  Next  to  this  initial  understanding  of  CEP,  it  was  decided  to  select  a  process 
being  analyzed  by  the  TTCP  JSA  TP4  group  and  to  evaluate  it.  An  analysis  of  this 
process  showed  clearly  many  differences  between  the  initial  perspective  and  the  one 
resulting  from  TP4  CEP  Working  Draft.  The  latter  introduced  many  new  concepts  and 
references,  all  aimed  at  improving  capability.  These  elements  increased  considerably 
the  degree  of  understanding  of  CEP.  Since  there  was  no  longer  a  single  perspective  of 
CEP,  further  investigations  have  been  done  to  identify  the  most  relevant  elements 
linked  to  CEP.  These  investigations  showed  there  exists  many  potential  perspectives  of 
the  CEP  concept. 

This  section  reflects  the  change  in  understanding  of  CEP,  mostly  based  on 
understanding  of  technologies  related  to  CEP.  The  first  part  of  this  section  is  organized 
around  three  subsections,  each  one  representing  a  perspective  (or  a  major  step  in  the 
project)  of  CE  and  its  process22:  the  initial  project  perspective  (Subsection  3.1),  the 
TP4  CEP  Working  Draft  analysis  perspective  (Subsection  3.2)  and,  finally,  the 
perspectives  resulting  from  further  investigations  (Subsection  3.3).  Our  hypothesis  is 
that  piecing  together  all  these  views  will  define  a  global  and  coherent  understanding  of 
the  possibilities  of  CEP.  Based  on  this  understanding  a  solution  can  be  chosen  within 
this  scope. 

Each  subsection  describes  CEP  according  to  the  following  aspects: 

•  Possible  Scopes  and  Specific  Objective:  our  investigations  identified  many 
possible  versions  of  the  concept  of  CE.  Most  of  these  interpretations  of  CE  are 
valid  since  they  contribute  to  the  set  up  and  improvement  of  military  capabilities 
in  the  CF.  The  possible  scopes  aspect  will  help  to  identify  all  possible  scopes  of 
the  CE,  all  of  them  able  to  contribute  to  the  same  final  objective.  With  all  the 
possible  scopes  defined,  it  will  be  possible  to  choose  a  scope  for  CE.  This  scope 


22  CE  is  a  concept  implemented  by  tools,  people  and  processes.  This  section  focuses  on  process  to 
implement  the  concept.  This  distinction  is  important  and  will  help  to  raise  questions. 
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will  help  to  define  the  specific  objective  of  the  CE.  This  scope  will  also  help  to 
delimit  the  boundaries  of  the  problem  and  the  solution  space  of  the  CE  concept. 

•  Candidate  Solutions:  Many  existing  approaches,  standards,  processes,  tools  etc., 
have  been  proposed  or  already  applied  to  similar  problems.  These  candidate 
solutions  can  all  be  used  to  develop  and  enrich  the  CEP.  These  technologies  will 
be  reviewed  and  be  put  into  context. 

•  Process  Forms:  Concepts  may  remain  theoretical  if  they  are  not  applied.  A 
rigorous  methodology  can  crystallize  this  concept.  It  is  called  a  process.  Even  if 
most  people  agree  on  what  is  a  process,  there  is  no  universally  accepted  form  of  a 
process.  The  reason  is  that  a  process  is  tailored  for  every  specific  domain.  This 
activity  requires  time  and  effort.  Therefore,  every  possibility  for  the  process  form 
should  be  determined  in  order  to  plan  a  process  development  strategy  over  a 
feasible  schedule. 

Each  perspective  will  raise  many  questions  in  regard  of  these  aspects.  These  questions 
will  be  highlighted  by  a  box  inserted  in  the  text.  Finally,  Subsection  3.4  synthesizes 
the  information  presented  in  the  previous  subsections  and  presents  candidate  solutions, 
possible  scopes,  specifics  objectives  and  process  forms.  This  integrated  version  is  the 
basis  that  was  used  to  understand  the  details  of  a  CEP. 

To  sum  up,  the  outcomes  of  this  section  will  be  to: 

•  demonstrate  that  the  initial  project  view  and  the  TP4  CEP  Working  Draft  had  a 
good  but  too  limited  (or  too  concise)  definition  of  a  process  and  CE. 

•  determine  the  possible  dimensions  of  the  scope  in  the  CE,  the  possible  form  of  the 
process  enabling  this  concept  and  the  specific  objectives  of  the  CE. 

•  present  some  candidate  solutions  that  are  already  used  in  the  solving  of  similar 
problems. 

3.1  Initial  Perspective 

The  first  perspective  of  CEP  is  the  one  described  partially  in  the  definition  of  the 
CapDEM  TDP:  the  initial  version  of  the  Project  Charter  [9]  and  the  PIP  [12].  Although 
the  description  is  focused  on  the  definition  of  the  project,  both  documents  help  to 
understand  CEP.  These  documents  already  propose  many  candidate  solutions  as  part 
of  the  CEP.  The  initial  perspective  also  includes  the  understanding  of  CEP  from 
SysEng  and  SoS  literature.  The  following  paragraphs  present  these  candidate  solutions 
or  domains  and  try  to  define  the  previously  mentioned  aspects  for  CEP. 

3.1.1  US  Naval  Collaborative  Engineering  Environment  (NCEE) 

Firstly,  the  US  NCEE  is  an  important  enabler  for  the  concept  of  CE.  It 
“enables  a  multi-disciplinary  development  team  to  address  all  engineering 
activities  in  a  comprehensive  and  integrated  manner”  [12].  The  NCEE 
actually  integrates  many  commercial  engineering  tools:  DOORS  [78],  CORE 
[85],  Interchange  [80]  and  Rational  Rose  [43].  These  tools  support  many 
activities  of  SysEng.  The  NCEE  relies  on  the  efficient  use  of  these  tools  to 
improve  the  development  of  a  capability.  It  cannot  be  defined  independently 
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of  the  process.  Ideally,  a  process  should  not  be  tailored  to  fit  with  a  specific 
toolset.  However,  limitations  of  tools  could  limit  the  usability  of  the  process. 
Inversely,  the  toolset  should  support  the  process. 


Do  the  NCEE  tools  represent  the  best  configuration  to  support  the  CEP? 


3.1.2  SoS  and  Complexity  Issues 

The  PIP  refers  to  the  concept  of  “Capability  as  a  SoS”.  It  defines  the  SoS  as 
“an  assemblage  of  components  which  individually  may  be  regarded  as 
systems  and  ...”  and  have  a  managerial  and  operational  independence.  SoS 
[15]  implies  the  study  of  the  complexity  underlying  the  development  and  the 
use  of  multiple  collaborative  systems.  Since  a  capability  is  the  result  of 
merging  one  or  more  system(s),  this  field  requires  to  be  examined  carefully  in 
CEP.  The  link  between  a  capability  and  a  SoS  is  not  clear. 


It  is  not  clear  at  which  level  a  SoS  becomes  a  synonym  for  capability, 
assuming  that  the  two  can  be  compared? 


The  answer  to  this  question  is  partially  related  to  the  definition  of  a  system. 
For  instance,  the  IEEE  1220  defines  a  system  as  “a  set  or  arrangement  of 
elements  (people,  products  -hardware  and  software-  and  processes  -facilities, 
equipment,  material,  and  procedures-...”23  If  a  system  includes  people, 
products  and  processes,  the  meaning  of  a  SoS  get  closer  to  the  meaning  of  a 
capability.  However,  other  elements  not  specifically  pointed  out  by  this 
definition  should  be  also  included  in  a  capability. 

Further  reading  [60]  on  SoS  issues  have  shown  that  SysEng  could  build  or 
evolve  various  types  of  SoS.  For  instance,  large-scale  component  systems  can 
be  specifically  designed  to  work  together.  This  type  of  SoS,  called  dedicated , 
is  constructed  over  a  long  period  of  time.  Another  type  of  SoS,  called  virtual , 
can  be  created  to  support  specific  military  operations.  In  a  virtual  SoS,  the 
various  systems  are  not  designed  initially  to  be  integrated.  These  SoS  are 
generally  constructed  in  a  short  period  of  time  to  meet  specific  mission 
requirements  and  are  dismantled  after  the  operation.  Cook  [20]  claims  that  it 
is  essential  to  make  a  distinction  between  these  two  since  the  acquisition 
imperatives  for  each  type  are  different.  Some  of  these  systems  are  also 
referred  to  as  Family-of-Systems24  (FoS)  and  federation-of-sy stems.  These 
terms  remain  to  be  studied. 


23  [44]  p.  10. 

24  A  “family-of-systems”  is  a  set  or  arrangement  of  independent  (not  interdependent)  systems  that  can 
be  arranged  or  interconnected  in  various  ways  to  provide  different  capabilities.  The  mix  of  systems  can 
be  tailored  to  provide  desired  capabilities  according  to  the  mission.  Under  today’s  warfighting, 
assembly  of  forces  for  contingencies  is  primarily  ad  hoc,  based  on  a  generic  set  of  requirements  rather 
than  preplanning  that  designates  specific  forces  for  a  particular  contingency.  Thus,  interoperability  of 
the  independent  platforms  is  a  key  consideration  in  the  ad  hoc  deployment  of  a  “family-of-systems” 
[40]. 
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Should  CE  be  able  to  construct  virtual  (short-term  time  frame)  and 
dedicated  (long-term  time  frame)  capabilities? 


The  way  that  a  SoS  evolves  is  another  important  concern  for  CEP.  For 
example,  Chen  and  Clothier  [15]  identified  three  types  of  evolution  for  a  SoS: 
self-evolution  Joint  evolution  and  emergent  evolution.  The  first  type  goes 
through  the  evolution  of  a  system  (part  of  the  SoS)  without  changing  any 
interface  of  others  systems.  The  second  type  refers  to  the  integration  of  two  or 
more  systems  (part  of  a  SoS)  to  improve  interoperability  and  business 
support.  Finally,  the  emergent  evolution  designates  the  development  of  a  new 
system  “on  the  basis  of  or  in  relation  to  existing  systems  with  new 
functionalities  or  capabilities.”  [60].  This  list  is  by  no  means  complete. 


Should  CEP  be  concerned  with  self-evolution,  joint  evolution  and  emergent 
evolution  (or  any  other  types  of  evolution)  of  a  capability? 


Chen  and  Clothier  [15]  also  suggest  that  SoS  SysEng  cannot  be  limited  to  the 
traditional  SysEng  issues  at  the  development  level.  The  authors  assert  that  the 
SoS  SysEng  should  deal  with  managerial  complexity  (for  instance,  support  of 
concurrent  engineering).  This  complexity  can  represent  itself  as  an 
engineering  issue. 


Is  CEP  more  related  in  solving  these  managerial  issues  of  concurrent 
engineering  instead  of  traditional  (but  complex)  SysEng  issues? 


The  complexity  issues  inherent  to  SoS  and  capability  have  been  discussed  in 
numerous  documents.  For  instance,  some  papers  [3][53][64]  have  analysed 
and  proposed  some  solutions  or  advices  that  help  to  deal  with  such 
complexity.  The  challenge  is  to  decompose  the  problem  into  smaller  (and 
simpler)  parts  while  preserving  the  global  vision  and  complex  interrelations. 
CEP  should  look  at  these  solutions. 

The  new  way  of  doing  engineering  [1 5][20][3]  in  the  context  of  SoS  imposes 
an  important  change  (or  an  evolution)  of  the  traditional  SysEng  approach. 

This  approach  consisted  of  dividing  a  relatively  complex  problem  into 
smaller  problems  that  were  simpler  to  solve  individually.  Then,  all  sub¬ 
solutions  found  were  put  together  into  a  global  solution  without 
systematically  considering  links  and  effects  between  these  solutions.  This 
method  resulted  in  a  so-called  reductionist  way  of  finding  solutions.  The 
global  solution  was  good  for  highly  deterministic  systems  that  are  non 
autonomous  (or  that  are  dependent  of  the  whole  to  have  a  life).  It  is  probably 
inadequate  for  SoS  involving  non-deterministic  behaviours  with  independent 
systems  (that  may  have  a  life  apart  from  the  whole  SoS). 

For  the  new  paradigm  inherent  to  SoS,  the  independent  systems  must 
collaborate  to  provide  the  needed  capability.  This  collaboration  involves 
complex  exchanges  of  information  that  may  cause  complex  behaviours  within 
the  SoS.  A  holistic  approach  giving  a  global  view  of  the  whole  SoS  is  thus 
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needed  to  allow  the  understanding  of  complex  behaviours.  This  implies  the 
consideration  of  all  factors  (or  elements  of  information)  and  links  between 
them  that  may  affect  the  whole  SoS  (or  capability). 

There  is  a  scoping  problem  with  this  new  holistic  approach.  For  complex  and 
large  SoS,  it  is  not  possible  to  consider  all  factors  and  links.  The  reason  is  that 
the  number  of  these  factors  and  links  between  them  is  too  high  (for  the  human 
brain  and  for  actual  CASE  tools).  A  trade-off  analysis  is  thus  needed  (within 
this  holistic  context)  to  define  and  establish  a  strategic  scope  that  will  bring 
the  number  of  factors  and  links  to  an  acceptable  level,  while  still  allowing  the 
SoS  to  provide  the  needed  capability.  The  scope  would  keep  only  the  factors 
and  links  that  may  have  a  medium-to-strong  impact  on  the  act  of  providing 
the  capability.  This  “medium-to-strong”  threshold  will  always  depend  on  the 
efficiency  of  the  SoS  to  deliver  the  capability.  The  greater  efficiency  needed, 
the  lower  the  threshold  will  have  to  be  and  thus  the  greater  number  of  factors 
and  links  will  have  to  be  considered. 


What  are  the  elements  within  the  CEP  that  will  help  the  trade-off  analysis 
for  the  identification  of  all  important  factors  and  links  that  should  be  taken 

into  account? 


3.1.3  IEEE  1220 

The  IEEE  1220  SysEng  process  [44]  is  another  potential  solution  that  has 
been  investigated.  As  described  in  the  process  definition  document,  “this 
standard  defines  the  requirements  for  an  enterprise's  total  technical  effort 
related  to  development  of  products  (including  computers  and  software)  and 
processes  which  will  provide  life-cycle  support  (sustain  and  evolve)  for  the 
products.”  Consequently,  this  process  enables  best  practices  and  rigorous 
methodology  to  develop,  sustain  and  evolve  single  system.  Since  a  capability 
is  based  at  least  on  one  system,  such  approach  might  contribute  to  help  at 
setting  up  and  improving  military  capabilities.  In  the  case  where  a  capability 
results  from  the  collaboration  of  many  systems  (SoS),  chances  are  that  this 
standard  process  should  be  updated.  This  process  is  a  potential  solution  that 
could  be  adapted  to  the  capability  context. 

Based  on  the  analysis  of  the  1220,  investigations  turned  towards  others 
enhanced  development  methodology  (spiral,  incremental,  iterative,  waterfall, 
etc.)  and  others  SysEng  processes  (ISO/IEC  12207  [47],  EIA  63225  [39]...) 
and  theories  [5]. 

3.1 .4  Role  of  the  Life  Cycle  in  the  CE 

The  definition  of  the  CE  is  strongly  related  to  the  life  cycle  of  systems 
participating  in  the  capability  and  to  the  life  cycle  of  the  capability  itself. 

Figure  8  illustrates  the  possible  phases  by  which  a  system  can  undergo. 


25  [77],  this  paper  shows  the  processes  of  EIA  632  in  Figure  2. 
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time 

Figure  8:  System  Life  Cycle  (SLC)  from  Lust  to  Dust  is  this  figure  extracted  from 
one  of  the  reference?  (Modified  from  [5],  p.  6) 

The  relation  of  the  life  cycle  with  the  CE  is  twofold.  On  one  hand,  the  CE  can 
consider  only  some  phases  of  the  life  cycle  of  the  constituent  systems  and  of 
the  capability  itself.  For  instance,  taking  into  account  considerations  like 
disposal,  maintenance,  manufacturing  and  training  could  result  in  a  slightly 
less  performing  system  in  the  battlefield  but  could  increase  greatly  its 
maintainability,  training,  disposal  and  so  on.  The  performance  on  the 
battlefield  and  the  initial  purchase  cost  are  not  anymore  the  only  variables  to 
optimize  in  the  design.  In  order  to  apply  good  engineering  practices,  all 
phases  of  the  life  cycle  should  be  considered.  However,  the  cost  to  consider 
all  of  them  could  be  too  prohibitive.  Resources  and  time  limitations  will  lead 
to  a  trade-off. 


Should  the  trade-off  between  different  phases  be  the  art  and  science  of  CE? 

On  the  other  hand,  the  CE  can  be  applied26  during  all  or  some  part  of  the  life 
cycle  of  a  capability27.  As  illustrated  in  Figure  8,  the  SysEng  does  not 
address  all  phases  of  the  life  cycle.  As  for  the  SysEng,  the  CE  can  only  go 
through  some  of  these  phases.  For  instance,  the  CE  could  be  involved  only  in 


26  The  difference  between  “consider”  and  “be  applied”  is  fundamental  here. 

27  The  term  life  cycle  of  a  capability  refers  to  the  phases  of  the  elements  related  to  a  capability  like  the 
included  systems  or  the  management  activities. 
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the  concept  definition  phase28  and  could  leave  the  detailed  configuration  item 
design  to  traditional  SysEng. 


During  which  phases  of  the  life  cycle  the  CE  is  applied? 


The  nature  of  a  capability  in  relation  to  the  systems  supporting  it  will 
influence  the  answer  to  these  two  questions.  Assuming  a  capability  includes  a 
single  system,  the  life  cycle  of  a  capability  would  be  equivalent  to  the  life 
cycle  of  this  system29.  However,  in  the  case  that  a  capability  includes  many 
systems  (SoS),  the  capability  life  cycle  would  not  necessary  follow  these 
phases.  If  all  systems  composing  the  capability  were  created  from  scratch  (but 
even  having  an  operational  and  managerial  independence),  the  life  cycle  of 
the  capability  might  be  approximately  the  same  life  cycle  as  all  included 
systems.  In  cases  where  a  capability  already  included  many  systems,  the 
phases  would  be  partially  related  to  the  introduced  (one  to  many)  systems  to 
the  existing  systems  and  to  the  capability  creation  itself. 

3.1.5  Methodology  and  Process  Model 

Another  important  element  to  consider  for  CEP  is  the  methodology,  or 
process  model  [14]  used  to  develop  the  systems.  To  name  a  few,  the  spiral, 
incremental,  iterative  and  waterfall  models  are  all  examples  of  methodology. 
Depending  on  the  organizational  environment  and  the  nature  of  the 
application,  different  process  models  will  be  required.  These  process  models 
can  be  applied  at  two  levels:  on  the  capability  development  (or  evolution) 
itself30  and  on  the  development  of  underlying  systems.  If  the  organizational 
environment  and  the  nature  of  application  are  similar  for  most  capabilities, 
CEP  could  support  a  single  (optimized)  process  model.  Otherwise,  this 
decision  could  be  left  to  individual  organization.  It  would  be  possible  to 
choose  the  most  adapted  methodology  to  each  capability  context. 


Should  CEP  be  tailored  to  an  optimal  process  model? 


3.1.6  DoDAF 

DoD  AF  [28] [29] [30]  is  an  architecture  framework  that  could  facilitate  the 
conception,  the  development,  the  improvement,  and  sustainment  of 
capabilities.  It  is  described  as  follows:  “The  DoD  AF,  Version  1.0,  defines  a 
common  approach  for  US  DoD  architecture  description  development, 
presentation,  and  integration.  The  framework  is  intended  to  ensure  that 
architecture  descriptions  can  be  compared  and  related  across  organizational 
boundaries,  including  Joint  and  multinational  boundaries.”.  This  framework 
is  based  on  4  related  views  of  architecture:  Operational  Views  (OV),  System 


28  Interoperability  considerations  between  systems  would  be  managed  in  this  phase  in  this  example. 

29  The  veracity  of  this  assertion  depends  of  what  is  engineering  to  get  (or  improve,  update)  a  capability. 

30  The  capability  development  methodology  can  be  replaced  by  acquisition  strategy.  The  latter  will  be 
presented  in  the  Subsection  3.3. 
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Views  (SV),  Technical  Views  (TV),  and  All  View.  These  views  contain 
graphical,  tabular,  or  textual  representation  of  architecture  information.  The 
DoD  AF  is  based  on  a  data  model  called  the  Core  Architecture  Data  Model 
(CADM)  [68].  CADM  defines  the  data  structure  and  relationship  for 
architecture  information. 

This  technology  is  useful  to  describe  both  hardware  and  software 
architectures.  It  can  improve  the  interoperability  of  the  various  systems 
participating  in  the  capability.  Therefore,  the  architecture-oriented  approach 
is  a  candidate  approach  that  could  be  part  of  CEP. 

3.1 .7  Synthetic  Environment  Based-Acquisition  (SEBA) 

SEBA  is  another  important  concept31.  Introduced  in  the  PIP,  the  SEBA 
project  objectives  were  to  “define,  implement  and  demonstrate  how  a 
synthetic  environment  can  be  used  to  provide  an  integrated  concept 
development  and  experimentation  capability  to  support  faster/better/cheaper 
acquisition  decisions.”  [12].  Even  if  the  approach  is  different,  these  objectives 
are  similar  to  the  CEP  objectives.  Consequently,  the  SEBA-like32  concepts 
would  play  an  important  role  in  reaching  the  CEP  objectives.  Like  for  the 
NCEE,  CEP  will  probably  have  to  be  adapted  in  order  to  enable  the  SEBA- 
like  concepts.  Moreover,  theses  concepts  will  have  to  be  adapted  to  CEP. 


What  role  might  SEBA  play  in  CEP? 


3.1.8  Capability  Based  Planning 

The  CBP  concept  [86]  is  strongly  related  to  CE.  “The  concept  recognizes  the 
interdependence  of  systems  (including  materiel  and  people),  doctrine, 
organization  and  support  in  delivering  defence  capability,  and  the  need  to  be 
able  to  examine  options  and  trade-offs  among  these  capability  elements  in 
terms  of  performance,  cost  and  risk  so  as  to  identify  optimum  force 
development  investments.”33.  This  concept  includes  other  enabling 
technologies  like  SMARRT  and  CDE.  It  also  recognizes  the  importance  of 
SysEng  and  its  toolset  (like  NCEE)  “to  support  the  rigorous  examination  of 
the  issues  that  drive  system  performance  and  integration  at  sufficient  detail  to 
enable  system  implementation.”34.  This  definition  is  closely  related  to  the 
concept  CE  defined  in  the  PIP:  the  CE  should  help  to  ‘systematize’  the 
capability  development  process  by  adding  the  rigour  of  the  SysEng  process 
between  CBP  and  the  acquisition.  Many  questioning  about  the  relation 
between  CE  and  CBP  have  been  raised.  It  has  been  concluded  that  the 
relationship  between  all  these  elements  is  not  temporal  but  conceptual,  i.e.  CE 


1  SEBA  is  the  name  of  a  Canadian  project  (before  CapDEM),  and,  also,  the  name  of  the  UK  concept. 
32  Simulation  and  Modeling  for  Acquisition,  Requirements  and  Training  (SMART),  Simulation  and 
Modeling  for  Acquisition,  Requirements,  Rehearsal  and  Training  (SMARRT)  and  SBA  are  similar 
initiatives. 


34 


[86]  p.  2. 

[86]  p.  4. 
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does  not  follow  CBP.  However,  the  question  of  whether  CE  is  used  during 
the  acquisition  phase  (temporal  relationship)  remains  to  be  answered. 


Is  the  relation  between  the  CBP  and  CE  conceptual  or  temporal?  Can  CE 
take  place  during  the  acquisition? 


As  mentioned  previously,  a  capability  could  be  the  integration  of  many 
existing  systems.  These  systems  can  be  at  different  phases  of  their  life  cycle. 
Figure  9shows  an  example  of  a  capability  built  on  many  existing  systems. 
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Figure  9:  Systems  and  Capability  Management  [86] 

The  synchronization  and  replacement  of  these  systems  to  maintain  or  improve 
a  capability  will  be  a  challenging  issue.  However,  if  the  role  of  CEP  is  to 
enable  this  kind  of  capability,  it  is  not  clear  what  are  the  specific 
responsibilities  of  CEP  to  reach  this  objective. 


Does  the  CE  choose  among  existing  systems  to  create  a  capability,  or  is 
this  role  dictated  by  the  CBP  or  the  Capability  Management? 


In  the  latter  case,  if  the  system  is  chosen  by  the  CBP,  the  CE’s  responsibility 
would  be  to  create  or  sustain  compatibility  among  existing  systems  (for  the 
doctrinal,  material  and/or  training  aspect)  and  would  plan  (or  develop)  the 
interoperability  of  the  new  added  system(s).  If  the  CBP  is  a  concept  only  and 
not  a  step  in  the  development  of  a  capability,  CE  could  be  its  implementation 
and  there  is  no  contradiction.  Otherwise,  overlap  between  the  CE  and  the 
CBP  remains  to  be  clarified. 

3.1.9  Discussion 

In  summary,  the  initial  perspective  on  CEP  already  includes  many  solutions. 
Should  CEP  be  created  from  all  these  solutions?  Is  there  any  gap,  overlap  or 
contradiction  between  these  solutions?  When  piecing  together  most  of  these 
technologies,  the  project  description  and  the  actual  possible  scopes,  our 
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understanding  of  the  CEP  specific  objective  will  be  to  adapt  engineering 
methods,  traditionally  used  in  a  system  context,  to  create  SoS.  In  this  initial 
perspective,  a  capability  is  roughly  a  synonym  of  SoS.  CEP  is  a  kind  of 
enhanced  IEEE  1220,  ISO/IEC  12207  or  Rational  Unified  Process  (RUP) 

[56] [42]  adapted  to  SoS  context.  The  process  takes  into  account  all  life  cycle 
phases  (ex:  manufacturing,  deployment,  training,  maintenance,  disposal)  and 
is  applied  during  most  of  the  SysEng  life  cycle  (detailed  design,  integration, 
production  and  manufacturing)  to  create  a  SoS.  The  scope  is  not  limited  to  the 
architectural  part  but  also  to  detailed  design.  Consequently,  the  output  is  one 
or  many  systems  forming  the  capability.  It  includes  a  significant  technical 
component  and  a  minor  business  component35. 

3.2  TP4  CEP  Working  Draft  Perspective 

The  CEP  Team’s  final  objective  is  to  propose  a  process  that  will  enable  the  CE 
concept.  Instead  of  opting  for  the  development  of  an  entirely  unique  CEP  of  its  own, 
the  project  team  was  directed  to  consider  for  analysis  (and  eventually  for  adoption  if 
proven  appropriate)  an  existing  perspective  resulting  from  the  efforts  of  an 
international  team  (TTCP  JSA  TP4).  The  perspective  is  known  as  the  TP4  CEP 
Working  Draft.  This  process  is  described  in  the  document  entitled  “Overview  of  the 
Capability  Engineering  Process”,  produced  in  June  2003  and  prepared  for  TTCP  JSA 
TP4  by  Mr  Richard  Schmidt  of  Systems  Technology,  Inc.  [75].  This  reference  can  be 
found  in  Annex  A.  An  analysis  quickly  revealed  that  this  process  was  based  on  a 
different  understanding  of  the  CE  concept.  Moreover,  the  implementation  of  this 
concept  into  a  process  did  not  meet  the  expectation  following  the  initial  works.  This 
subsection  presents  the  perspective  of  CEP  from  the  TP4  CEP  Working  Draft 
description. 

At  the  same  time,  CEP  Team  had  chosen  to  consider  the  RDA  CHENG  NCEE  for 
supporting  the  CEP.  At  this  step,  CEP  Team  noticed  that  the  tools  that  were  supposed 
to  be  tailored  to  support  the  process  were  not  chosen  necessarily  for  this  purpose. 

These  tools  are  enablers  for  CEP  but  can  also  impose  some  constraints  on  it. 

Like  most  documents,  the  TP4  CEP  Working  Draft  description  defines  a  capability  as 
composed  of  many  systems  (then  as  a  SoS).  However,  the  kind  of  SoS  is  not  explicitly 
mentioned.  Are  these  SoS  virtual  or  dedicated?  The  answer  can  be  deduced  from 
references  to  long-term  timeframe  of  capability.  Since  a  dedicated  SoS  is 
created/evolved  on  a  long-term  basis,  the  TP4  CEP  Working  Draft  description 
probably  considers  only  a  dedicated  SoS.  Consequently,  the  capability  will  be 
created/evolved  over  many  years  and  not  within  a  few  weeks  or  months  to  counter  a 
new  and  specific  threat.  Even  if  the  process  unambiguously  associates  a  capability  to  a 
SoS,  it  does  not  define  the  size  or  granularity  of  this  capability.  This  capability 
granularity  problem  will  be  discussed  in  the  following  section. 

It  is  not  clear  from  the  above  reference  whether  the  TP4  CEP  Working  Draft  purpose 
is  to  create,  evolve  or  to  maintain  an  operational  capability.  The  document  only 
mentions  that  an  Initial  Operational  Capability  (IOC)  can  evolve  in  an  incremental 


35  DoD  AF  includes  an  important  business  part  but,  as  it  will  be  seen  later,  it  is  not  as  large  as  in  the 
enterprise  architecture. 
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way.  However,  it  is  impossible  to  know  if  this  IOC  is  an  evolution  of  an  existing 
capability  or  if  it  has  been  created  from  scratch.  This  concept  of  incremental  capability 
is  a  fundamental  aspect  of  the  evolutionary  acquisition36.  This  latest  concept  is  present 
in  the  process. 


Is  the  CEP  role  to  create,  evolve  and/or  maintain  a  capability? 


Unlike  traditional  SysEng  approaches  that  focus  mainly  on  the  system  aspect,  the  TP4 
CEP  Working  Draft  description  provided  by  Schmidt  also  includes  important 
organizational  and  business  details.  In  this  document,  the  architecture  description 
includes  the  organizational  structure,  the  roles  and  responsibilities  and  the  business 
processes  associated  with  the  organization  in  terms  of  systems  and  equipment.  The 
TP4  CEP  Working  Draft  is  described  as  taking  into  account  all  enterprise  layers37  to 
find  an  integrated  and  globally  optimal  solution.  This  “enterprise”  vision  of  a 
capability,  instead  of  solely  a  technical  vision,  will  be  discussed  further  in  the 
enterprise  architecture  of  the  following  section. 

In  the  second  figure  of  Schmidt’s  description  of  the  TP4  CEP  Working  Draft,  the  life 
cycle  for  a  capability  is  defined  in  three  steps:  operational  analysis,  CE  and 
evolutionary  acquisition.  It  ensues  that  the  CE  begins  right  after  the  Operational 
Analysis  activity  to  ends  up  just  before  the  system  acquisition.  It  occurs  concurrently 
to  the  concept  definition  phase  of  SysEng.  Thus,  it  is  not  applied  during  detailed 
design,  system  integration,  production  and  manufacturing,  and  others  phases.  The 
document  is  less  precise  about  the  phases  of  the  life  cycle  considered.  For  instance, 
does  this  process  take  into  account  manufacturing  or  maintenance  consideration? 

The  definition  of  the  capability  life  cycle  and  the  place  of  CEP  within  the  phases  of 
this  life  cycle  have  an  impact  on  the  input  required  by  CEP  and  the  output  produced  by 
CEP.  Since  one  step  must  deliver  its  work  to  another  step  with  deliverables,  it  is 
important  to  define  these  deliverables.  Even  though  the  activity  preceding  the  CE  is 
defined,  the  output  of  this  activity  and  consequently  the  input  of  the  CE  is  not  known. 
However,  the  deliverable  in  output  is  clearly  defined.  Surprisingly,  it  is  not  a  system  or 
a  capability  but  a  description  of  a  “vision”  integrated  architecture38,  documented  into  a 
transformation  roadmap.  This  document  contains  information  about  the  organisational 
evolution  plan,  the  capability  evolution  objectives,  the  capability  evolutionary 
roadmap,  the  force  training  and  transition  plan  and  the  investment  plan.  It  is  not 
explicitly  said  to  whom  this  document  is  intended. 


What  are  the  inputs  and  the  outputs  of  CEP? 
Who  will  use  this  information? 


The  process  also  generates  an  integrated  architecture  that  could  be  used  for  the 
acquisition  phase.  However,  this  integrated  architecture  is  not  defined  as  a  deliverable. 
Figure  10  clarifies  the  TP4  CEP  Working  Draft  by  locating  its  major  phases  and 
activities. 


36  See  next  subsection  for  more  information  on  Evolutionary  Acquisition 

37  See  next  subsection  for  more  information  on  the  layers  of  the  Enterprise  Architecture 

38  Architecture  created  with  DoD  AF  is  called  integrated  architecture. 
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2.1  Define  the  “as-is”  Integrated 
Architecture 

-  2.1.1  Capture  the  “as-is”  Operational  Model 

-  2.1.2  Capture  the  “as-is”  Physical  Model 

-  2.1.3  Identify  the  Measures  of  Effectiveness 

-  2.1 .4  Identify  Areas  of  Opportunity  for 
Improvement 

2.2  Establish  the  Strategic 
Vision 

-  2.2.1  Evaluate  Availability  of  Technology 

-  2.2.2  Evaluate  Doctrine  and  Tactic  Evolution 

-  2.2.3  Evaluate  Force  Structure  Evolution 

-  2.2.4  Document  the  Strategic  Vision 

2.3  Develop  the  “Vision” 
Integrated  Architecture 

-  2.3.1  Identify  Candidate  “Vision”  Architecture 
Alternatives 

-  2.3.2  Evaluate  Candidate  Alternatives  for 
Feasibility 

-  2.3.3  Select  Alternative(s)  for  Concept 
Development 


2.3  Develop  the  “Vision” 
Integrated  Architecture  (cont’d) 

-  2.3.4  Develop  Alternative(s)  Operational  Model 

-  2.3.5  Develop  Alternative(s)  Physical  Model 

-  2.3.6  Evaluate  Alternative(s)  Architecture 
Cost/Effectiveness 

-  2.3.7  Select  and  Document  the  Preferred 
Alternative 

2.4  Establish  the  Transformation 
Roadmap 

-  2.4.1  Identify  the  Organizational  (Force) 
Structure  Evolution  Plan 

-  2.4.2  Establish  Capability  Evolution  Objectives 

-2.4.3  Establish  Evolutionary  Acquisition 
Roadmap 

-  2.4.4  Establish  the  Force  Training  and 
Transition  Plan 

-  2.4.5  Establish  the  Investment  Plan 


Figure  10:  TP 4  CEP  Working  Draft  Activity  Breakdown  (from  [58]) 


This  “process”  defines  a  small  set  of  activities  grouped  into  four  major  activities. 
There  is  no  time  constraint,  triggered  or  triggering  activities  or  schedule  to  apply  the 
process  (see  section  4).  The  document  does  not  define  any  formal  or  standard 
deliverables,  aside  from  the  transformation  roadmap.  Moreover,  no  mention  of  who 
will  conduct  these  activities  is  given.  There  are  neither  any  entrance  criteria  for  each 
activity.  Finally,  the  process  remains  silent  on  tools  that  could  assist  to  apply  the 
process.  Should  CEP  complete  these  gaps? 


What  is  the  level  of  completeness  of  CEP  in  regard  of  What,  When, 
How  and  With  What  should  be  reached? 


Figure  1 1  shows  an  illustrated  and  interpreted  version  of  the  TP4  CEP  Working  Draft 
(activities,  phases  and  internal  information  exchanges).  It  is  based  on  deductions 
following  meticulous  readings  of  the  process.  It  shows  a  possible  time  schedule  of 
activities. 

This  process  remains  silent  on  the  methodology  that  could  be  used  for  the  SysEng  part. 


DRDC  Valcartier  TR  2004-230 


19 


2.2.1  1  2.2.2  1  2.2.3 

2.2.4 

2.2  Establish  the 

Strategic  Vision 

Document 

Strategic 

Vision 

I  2.1 ....  I  2.1.4~ 


2.1  Define  the  “As  is” 
Integrated  Architecture 


il 


t 


23A  1  2.3....  1  Z3 J 

2.3  Develop  the  “Vision” 

i  1 

Integrated  Architecture 

2.4  Establish  the 
Transformation  Roadmap 


Figure  11:  TP4  CEP  Working  Draft  Activity  Breakdown  versus  Time  (from  [58]) 


Another  important  concern  is  the  level  of  refinement  of  CEP  for  each  aspect  of  its 
completeness.  For  instance,  an  activity  of  CEP  requires  that  we  produce  a  deliverable 
called  Analysis  of  Alternatives  (AoA).  The  same  activity  could  also  require  that  we 
produce  a  Pugh  Matrix.  The  latest  is  a  format  to  present  an  AoA.  Even  if  it  could  be 
restrictive,  this  level  of  specificity  can  guaranty  interoperability  at  the  deliverable 
level.  Another  example  of  the  level  of  refinement  is  the  quantity  of  deliverables 
produced  during  the  process,  not  only  for  external  use  but  also  for  internal  information 
exchange.  The  TP4  CEP  Working  Draft  states  explicitly  only  one  deliverable.  On  the 
other  hand,  others  processes  like  the  SLC  of  the  Defence  Finance  and  Accounting 
Service  (DFAS)  [24]  states  dozens  of  deliverables.  Figure  12  shows  an  example  of 
deliverables  exchanges  between  activities  of  the  TP4  CEP  Working  Draft.  A  process 
could  be  refined  indefinitely  but  could  not  be  worth  the  investment  and  could  produce 
a  too  specific  and  restrictive  (but  optimal)  solution. 


What  are  the  levels  of  refinement  for  CEP  and  to  which  levels  of 
refinement  CEP  should  be  defined? 


This  process  is  independent  to  its  context  of  application.  Like  other  processes  that  will 
be  presented  later,  it  could  be  customized  or  tailored  to  better  conform  to  the  capability 
decision  and  development  process  of  a  specific  organization.  For  instance,  the  SLC 
approach  defines  a  set  of  activities  producing  a  series  of  deliverables  tailored  to  the 
decision  making  process  and  to  the  accounting  services  of  the  US  DoD. 


Should  CEP  be  generic  or  tailored  to  its  context  of  use? 
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Figure  12:  TP4  CEP  Working  Draft  Interpretation 
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3.2.1  Discussion 


The  CEP  described  in  the  Schmidt  paper  on  TP4  CEP  Working  Draft  is  a 
process  that  helps  the  creation  and/or  the  updating  and/or  the  maintenance  of 
a  capability  over  a  long  period  of  time.  Unlike  the  first  perspective  of  CEP,  its 
output  is  a  document,  not  a  system  or  a  capability.  This  document  contains  an 
AoA  and  the  investment  strategy  that  will  be  used  by  the  decision  maker  and 
the  acquisition  community39.  Like  most  SysEng  process,  this  CEP  is 
independent  of  its  context  of  application.  The  process  described  in  the  TP4 
CEP  Working  Draft  document  takes  into  account  both  the  technical,  business 
and  organizational  aspects  of  a  capability.  Moreover,  this  process  produces 
technical  and  organizational  solutions.  However,  it  is  not  possible  to  complete 
the  perspective  of  the  TP4  CEP  Working  Draft  because  many  aspects  are  not 
clearly  defined.  For  instance,  this  document  is  not  clear  whether  or  not  CEP 
takes  into  account  manufacturing  and  disposal  considerations.  Neither  does 
this  document  define  the  size  of  a  capability. 

Even  if  the  final  objective  is  the  same,  this  perspective  differs  considerably 
from  the  initial  one.  Since  many  valid  perspectives  (possibilities)  of  CEP  can 
all  reach  the  same  final  objective,  it  has  been  necessary  to  complete  the 
possibilities  of  what  CEP  could  be  by  performing  further  investigations. 

3.3  Other  Possible  Perspectives 

Previous  investigations  and  works  produced  incomplete  or  incoherent  views  of  the  CE 
concept.  For  instance,  it  has  been  observed  that  two  or  more  technologies  were 
tackling  at  the  same  problem.  It  was  also  impossible  to  know  the  specific  purpose 
(scope)  of  some  technologies.  Thus,  further  investigations  were  essential. 

Technologies,  that  are  able  to  participate  to  the  final  CE  objectives,  have  been 
reviewed  to  complete  the  two  previously  presented  perspectives.  This  section  will  not 
present  a  single  perspective  but  will  consider  all  candidate  solutions,  possible  scopes 
and  process  forms  from  all  angles. 

3.3.1  US  DoD  5000  and  Evolutionary  Acquisition 

The  TP4  CEP  Working  Draft  mentions  the  US  DoD  Directive  5000.1  [34] 
and  US  DoD  Instruction  5000.2  [35][36][37].  These  documents  enable  and 
standardize  the  concept  of  the  Evolutionary  Acquisition  strategy.  The  US 
DoD  5000  Instruction  and  Directive  documents  specify  the  Evolutionary 
Acquisition  and  the  Spiral  Development  Model  as  the  most  appropriate 
approaches  for  the  acquisition  in  US  DoD.  The  approach  begins  with  a  series 
of  explorations  to  ensure  the  technology  readiness  and  then  proceed  by  doing 
Spiral  Developments  for  a  number  of  funding  blocks.  This  approach  has  to 
adapt  to  a  changing  environment  by  rapidly  acquiring  and  sustaining  a 
supportable  core  capability  and  incrementally  inserting  new  technologies  or 
additional  capability  features,  as  they  are  available  and  mature.  A  basic 


39  The  term  acquisition  means  the  activity  following  the  capability  definition  phase  like  in  the  TP4  CEP 
Working  Draft  proposal. 
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capability  is  fielded  with  the  intent  to  develop  and  field  additional  capabilities 
as  requirements  are  refined.  The  role  of  this  approach  is  to  reduce  the  time  a 
capability  can  be  transferred  to  the  field  and  used  efficiently  in  the  form  of 
system  (or  SoS).  These  initiatives  clearly  share  the  same  objective  as  CEP. 
However,  at  which  level  exactly  the  Evolutionary  Acquisition  and  DoD  5000 
are  related  to  CEP  is  a  study  to  complete. 

The  DoD  5000  do  not  define  completely  which  phases  of  the  life  cycle  it 
considers.  However,  they  are  well  scoped  in  regard  of  the  phases  of  the  life 
cycle  during  which  they  are  applied.  They  apply  from  concept  refinement  to 
disposal  (concept  refinement,  technology  development,  system  development 
and  demonstration,  production  and  deployment,  operations  support  - 
disposal).  The  phases  before  concept  refinement  are  done  by  the  Joint 
Capability  Integration  and  Development  System  (JCIDS)  of  the  Chairman  of 
the  Joint  Chiefs  of  Staff  Instructions  (CJCSI)  3170  [19].  The  DoD  5000 
receive  as  input  a  document  called  Initial  Capabilities  Document  (ICD)  in 
which  the  capabilities  and  material  solutions  are  roughly  defined. 

The  DoD  5000  are  not  designed  to  produce  a  complete  capability.  Even  if  it 
takes  into  account  many  components  of  a  capability  like  Doctrine, 
Organizations,  Training,  Materiel,  Leadership,  Personnel  and  Facilities 
(DOTMLPF),  it  only  proposes  a  material  solution. 


Should  CEP  consider  and  propose  a  solution  for  all  these  aspects  (such  as 
DOTMLPF  or  PRICIE) 40  or  be  more  selective  like  the  5000  acquisition 

strategies? 


Like  the  TP4  CEP  Working  Draft,  the  DoD  5000.1  participates  in  defining 
Capability  Roadmaps,  Capability  Assessments,  Investment  Strategies  and 
Integrated  Architecture.  The  purpose  of  these  documents  is  to  integrate  the 
requirements  with  the  acquisition,  i.e.  integrate  CJCSI  3170  requirement 
process  with  the  DoD  5000  acquisition  process. 

The  bridge  between  the  requirement  of  a  capability  (regulated  by  CJCSI  3170 
requirement  process  in  the  US)  and  the  acquisition  of  a  capability  (regulated 
by  the  DoD  5000  directive  and  instruction  in  the  US)  is  essential  to  the 
successful  creation  and  improvement  of  this  capability.  This  concept  is  called 
Capability-Based  Methodology.  Such  bridge  is  possible  by  using  an 
integrated  architecture.  DoD  has  developed  the  DoD  AF  framework  to  come 
with  such  an  integrated  architecture.  However,  other  similar  frameworks41 
from  the  Enterprise  Architecture  community  are  also  good  candidates  (similar 
or  complementary)  that  could  be  used  to  reach  similar  objectives. 


40  PRICIE  (Personnel,  R&D/Ops  Research,  Infrastructure  &  Organization,  Concepts,  Doctrine  & 
Collective  Training,  IT  Infrastructure,  Equipment,  Supplies  and  Services)  is  the  Canadian  version  of 
DOTMLPF. 

41  See  next  Subsection. 
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3.3.2  Enterprise  Architecture 

Enterprise  Architecture  [61]  and  its  engineering  should  be  considered  in  the 
elaboration  of  CEP.  For  instance,  the  TP4  CEP  Working  Draft  was  defined  to 
be  the  combination  of  the  Enterprise  Architecture  Concepts  and  the  System 
Acquisition  Process.  The  purpose  of  an  enterprise  architecture  “is  to  support 
the  company's  corporate  vision  and  strategy.  Therefore  the  company’s  vision 
and  strategy  must  be  allowed  to  support  and  define  all  elements  and  aspects 
of  the  enterprise  architecture.  If  properly  defined  and  managed,  an  enterprise 
architecture  will  serve  to  control  and  contain  costs  throughout  the  lifecycle  of 
the  project.”42.  This  cost-control  and  corporate  vision  are  closely  related  to 
the  objectives  of  CEP  and  the  means  used  by  the  TP4  CEP  Working  Draft  to 
reach  its  objectives. 

An  enterprise  architecture  is  always  composed  of  a  number  of  sub¬ 
architectures.  Even  if  there  is  no  common  agreement  on  what  should  be 
included  in  Enterprise  Architecture,  it  always  contains  a  business  and  a  more 
technical  portion,  as  illustrated  in  Figure  13. 


Figure  13:  Enterprise  Architecture  Layers  (from  [54]) 

The  business  level  describes  the  business  strategies,  the  processes,  and  the 
functional  requirements  that  are  needed  to  support  the  business  goals  and 
objectives.  It  can  include  how  the  organisation  works,  both  the  administration 
and  the  operational  portion  of  the  enterprise.  The  technical  part  is  more 
related  to  technologies  required  to  support  the  enterprise  changes  (used  or 


42  JP  Rushing  Consulting.  2003.  Available  at 
http://www.ipmshing.com/ECM/Enterprise  Architecture. asp 
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produced).  In  the  CapDEM  project,  the  capability  improvement  or 
development  should  require  business  and  technical  modifications.  Until  now, 
most  solutions  related  to  CEP  dealt  mainly  with  the  technical  layer  of  the 
enterprise.  The  integrated  architecture  in  DoD  AF  is  an  exception  since  its 
operational  models  include  a  business  portion. 


Should  CEP  deal  with  the  technical  layer  only,  the  technical  and  a  part  of 
the  business  layer  like  in  an  integrated  architecture  or  go  further  by 
including  both  technical  and  most  business  aspects  such  as  organization 
operations  like  in  the  TP4  CEP  Working  Draft? 


If  CEP  tackles  all  the  life  cycle,  the  process  would  cover  the  technical  aspect 
entirely  in  its  smallest  detail.  On  the  other  hand  where  CEP  scope  is  restricted 
to  some  portion  of  the  life  cycle  like  in  the  TP4  CEP  Working  Draft  (it  stops 
at  the  transformation  roadmap),  it  is  not  clear,  for  both  technical  and  business 
layers,  how  broad  and  which  level  of  detail  should  be  covered.  The  cost 
associated  to  plan  a  detailed  design  would  be  very  high  and  would  contradict 
the  concept  of  the  planning  in  which  a  small  portion  of  total  resources  is  spent 
in  order  to  plan  the  order  portion.  However,  the  necessity  to  drill  down  the 
design  of  some  parts/systems  of  the  technical  or  business  level  can  be 
justified  by  reducing  the  risks  and  the  unknowns  of  the  project.  This  way, 
managers  could  take  the  decision  on  solid  basis  even  if  the  design  of  the 
various  components/systems  is  not  entirely  completed. 


Which  level  of  detail  and  of  broadness  should  be  reached  for  the  business 

and  the  technical  level? 


The  Enterprise  Architecture  is  commonly  used  by  various  enterprises  in  the 
world.  The  general  concept  is  well  understood  but  each  enterprise  has  adapted 
it  to  its  own  individual  needs.  The  Open  Group’s  Architecture  Framework 
(TOGAF)  [79],  the  DoD  AF,  the  US  Federal  Enterprise  Architecture 
Framework  (FEAF)  [17],  the  Zachmann  Framework  [88]  for  Enterprise 
Architecture,  and  the  US  Treasury  Enterprise  Architecture  Framework 
(TEAF)  [25]  are  all  examples  of  enterprise  architectures.  Many  of  them  have 
a  strong  acceptance  in  the  civil  domain. 

3.3.3  Transformation  Roadmap 

The  deliverable  of  the  TP4  CEP  Working  Draft  is  a  Transformation  roadmap. 
This  document  contains  information  about  the  organisational  evolution  plan, 
the  capability  evolution  objectives,  the  capability  evolutionary  roadmap,  the 
force  training  and  transition  plan  and  the  investment  plan.  This  information  is 
intended  to  help  the  decision-making  and  the  acquisition  process.  The  US 
DoD  uses  a  similar  transformation  roadmap.  All  US  DoD  Services  must 
produce  every  year,  in  accordance  with  the  Defence  Planning  Guidance  [65], 
a  roadmap  [18][82][83]  that  explains  how  they  will  build  the  capabilities 
necessary  for  executing  the  six  critical  operational  goals  identified  in  the 
quadrennial  Defence  Review  Report  [33].  These  capabilities  (26  for  two  of 
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the  three  documents)  are  called  transformational  capabilities.  However,  it 
seems  that  the  capabilities  described  in  these  documents  are  at  a  higher  level 
(or  bigger)  than  the  capabilities  described  in  TP4  CEP  Working  Draft. 


Since  a  capability  can  be  defined  at  various  level  of  granularity,  which 
level  is  optimal  to  reach  the  objectives  of  CEP? 


An  extension  of  this  question  is  the  following: 


Should  CEP  cover  a  single  or  many  capability(ies)? 


If  a  capability  can  be  decomposed  into  many  smaller  capabilities,  this 
question  is  meaningless. 

3.3.4  Large  Scale  System  Engineering  Process  (LSSEP) 

The  RDA  CHENG  group  is  actually  working  on  the  LSSEP  [31].  “The  term 
LSSEP  is  meant  to  define  the  SysEng  processes  for  Integration  and 
Interoperability  (I&I)  of  FoS  or  SoS”.  Like  many  other  solutions,  LSSEP 
final  objective  intersects  considerably  with  those  of  CEP.  Like  the  TP4  CEP 
Working  Draft,  it  defines  a  strategic  capability  plan  and  a  capability  evolution 
document.  The  following  sentences  resume  the  role  of  LSSEP  in  the 
acquisition: 

“The  BCAPP  (Battleforce  Capability  Assessment  and  Programming  Process) 
and  the  Acquisition  of  Major  and  Non-major  Systems  Process  do  not  run  in 
synchronization.  The  BCAPP  is  budget  driven  and  runs  on  the  budget  cycle. 
The  Acquisition  process  can  be  lengthy  and  is  milestone  driven.  As  FoS  and 
SoS  are  formed,  either  from  the  BCAPP  Capability  Evolution  Document 
(CED)  or  other  initiatives,  the  programs  that  are  grouped  together  to  achieve 
mission  capabilities  will  be  in  different  stages  of  their  life  cycle,  be  managed 
by  different  program  managers,  be  grouped  in  different  PEO’s  (Program 
Executive  Office),  or  supported  by  different  SYSCOMS.  Consequently,  the 
SysEng  IPT  becomes  the  critical  forum  for  identifying  and  resolving  I&I 
issues.  The  key  LSSEP  product  for  this  effort  is  the  Systems  Performance 
Document  (SPD).”  [31] 

The  LSSEP  is  composed  of  a  sequence  of  activities,  based  on  IEEE  1220, 
producing  a  set  of  documents:  an  Interim  Capstone  Requirements  Document 
(ICRD)  containing  the  operational  capability  description  and  the  Key 
Performance  Parameters  (KPPs),  an  Integrated  Strategic  Capability  Plan 
(ISCP),  an  Integrated  Sponsor  Program  Proposal  (ISPP)  document,  a 
Capability  Evolution  Document  (CED).  The  content  of  most  of  these 
documents  is  similar  to  the  deliverable  of  the  TP4  CEP  Working  Draft.  The 
ICRD  preceding  the  others  document,  however,  could  be  used  in  input  to  the 
TP4  CEP  Working  Draft.  If  LSSEP  were  translated  to  the  Canadian  context, 
CEP  would  extend  to  the  requirements  analysis  phase. 

The  deliverables  of  LSSEP  are  more  numerous  and  more  adapted  to  the 
decision  making  process  and  business  rules  of  the  US.  On  the  other  hand,  a 
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process  like  the  TP4  CEP  Working  Draft  can  deliver  organization 
independent  documents.  CEP  will  have  to  specify  deliverables  independent  of 
the  utilization  context  or  deliverables  tailored  to  the  (Canadian)  organization. 
This  choice  will  refer  as  its  level  of  adaptability  to  the  organization. 

Figure  14  is  taken  from  a  LSSEP  presentation.  It  is  clear  that  they  define 
capability  on  SoS  and  FoS. 


Program  A 
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Figure  14:  LSSEP  Presentation  (from  [73]) 

Like  the  CBP,  Figure  14  shows  the  need  to  manage  and  synchronize  various 
programs  (systems)  to  sustain  or  improve  a  capability. 

3.3.5  Discussion 

Many  industrial  and  military  technologies  and  approaches  presented  in  this 
section  may  help  in  setting  up  and  improving  military  capabilities  for  the 
Canadian  Forces.  The  possibilities  of  scope  are  larger  than  ever,  with 
solutions  extending  over  the  whole  life  cycle  and  extending  over  both 
technical  to  business  levels  of  the  enterprise.  Some  investigations  show  that 
the  process  can  be  tailored  closely  to  the  decision  making  process,  contrary  to 
what  has  been  encountered  in  the  previous  perspectives. 

3.4  CEP  Team  Understanding 

The  previous  sections  have  presented  existing  candidate  solutions,  scopes  and  process 
forms.  They  are  fundamental  to  define  or  evaluate  any  solution,  called  CEP  in  this 
project,  to  improve  acquisition,  maintenance  and/or  update  of  a  capability.  This  section 
summarises  these  candidate  solutions,  scopes  and  process  forms  to  create  an  integrated 
version  of  all  presented  perspectives. 

3.4.1  Candidate  Solutions 

As  a  recall,  the  main  goal  in  CapDEM  is  to  develop  a  CEP  that  will  help  at 
improving  decision-making  for  strategic  investment.  This  CEP  is  still  in  its 
infancy.  Work  must  be  done  to  identify  the  already  working  technologies  that 
could  be  introduced  within  the  CEP.  Additional  efforts  will  have  to  be  done 
in  order  to  identify,  define,  and  develop  all  missing  technologies  that  will 
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complete  the  CEP.  Figure  15  illustrates  some  technologies  that  are  already 
used. 


Which  existing  candidates  solution  should  be  taken  into  account  and 

included  in  CEP? 


Initial  CapDEM 
Project  Perspective 


us 

Solution 
Scope  / 


RDA  CHENG  CEP 
Proposal  Perspective 


System 
Development 
Planning 

Organization 
Engineering 

Reverse  .  .  .  . 

Engineering  Jnt®9ra‘ed 
a  Architecture 

(  as-is  ) 


V 


Transformation 
Roadmap  VI 


Canadian 

Solution 

Scope 


Figure  15:  Candidate  Solutions  from  Different  Perspectives 

As  shown  in  this  figure  (and  largely  discussed  in  earlier  sections),  there  are 
many  potential  industrial  and  military  solutions.  These  technologies  provide 
the  necessary  scientific  rigor  to  address  problematic  such  as  military 
acquisition  (Evolutionary  Acquisition,  US  DoD  5000  documents,  CJCSI 
3170...),  software  engineering  (RUP,  UML...),  SysEng  (IEEE  1220,  ISO/IEC 
12207,  Spiral  Development...),  architecture  description  (DoD  AF,  TOGAF, 
Zachmann,  Enterprise  Architecture...),  and  others. 
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Yet,  there  exist  no  standard  or  framework  that  allows  system  engineers  to 
completely  address  this  problematic.  Works  have  been  started  to  bring 
standard  SysEng  to  a  point  where  complexity,  which  emerges  from 
collaboration  between  autonomous  systems  (made  of  people,  processes,  and 
technologies),  becomes  more  deterministic,  predictable,  and  thus  manageable. 

The  starting  point  to  build/develop/create  the  CEP  is  the  actual  industry  and 
military  solutions  or  technologies  that  are  illustrated  in  Figure  15.  Some 
characteristics  of  this  set  of  technologies  relevant  to  CEP  Team  work  in  the 
CapDEM  project  are  the  following: 

•  They  were  mainly  conceived  in  US. 

•  There  are  overlaps  and  gaps  between  them. 

•  As  they  are  the  result  of  many  different  efforts,  these  solutions  are  not 
integrated. 

•  In  terms  of  levels,  their  scope  varies  but  is  often  at  an  enterprise  level. 

•  They  are  difficult  to  compare  and  thus,  to  evaluate. 

Many  questions,  not  easy  to  answer  at  this  moment  in  CapDEM  project,  can 
be  raised  at  this  moment: 

•  Which  technologies  (listed  in  Figure  15)  should  be  used  within  the  CEP 
and  in  what  order? 

•  Considering  the  needs  for  the  CEP,  how  should  these  technologies  be 
used  and  how  should  they  be  used  together,  are  they  complementary,  are 
they  compatible? 

•  Which  technologies  are  missing  to  complete  the  CEP? 

•  Are  CASE  tools  ready  to  support  these  technologies  (and  thus  the  CEP)? 

•  If  not,  does  a  strategy  need  to  be  established  (for  using  these 
technologies  and  tools)  that  will  follow  the  evolution  of  CASE  tools 
functionalities? 

CASE  tools  will  help  synchronize  the  use  of  all  technologies  within  the  CEP. 
It  is  probable  that  many  complementary  CASE  tools  (supporting  the 
concurrent  use  of  many  chosen  technologies)  will  be  involved  within  the 
CEP.  These  tools  will  have  to  be  able  to  be  used  concurrently  to  give  the  CEP 
all  its  efficiency  and  effectiveness. 

The  complexity  emerging  from  such  complex  projects  will  involve  many 
important  factors  (human,  technological,  procedural...)  and  links  between 
them.  These  will  have  to  be  considered  within  the  CEP  and  the  chosen 
technologies  and  tools  will  have  to  ease  their  consideration  and  their 
understanding  by  all  relevant  stakeholders.  For  example,  the  modification  of 
one  determinant  aspect  of  a  studied  architecture  (called  a  factor)  must  be 
reflected  at  all  relevant  other  locations  in  the  architecture  and  at  all  relevant 
stakeholder  levels  to  insure  the  needed  coherence  and  synchronization  in  the 
project.  The  CEP  and  its  technologies  will  have  to  provide  all  functionalities 
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that  will  support  the  propagation  of  all  relevant  information  at  all  relevant 
locations.  In  addition  to  traceability,  it  will  also  provide  means  to  insure 
coherence  and  synchronization. 

3.4.2  CE  Scope 

As  mentioned  at  the  beginning  of  this  section,  CE  can  be  interpreted  (or 
defined)  in  many  ways.  Its  scope  contains  many  possible  interpretations  of 
CEP.  This  scope  is  defined  into  three  main  categories:  (i)  capability 
characteristics,  (ii)  characteristics  to  consider  or  having  an  impact,  and  (iii) 
applications  to  obtain  a  future  capability. 

CE  can  be  conceived  from  a  selection  of  various  possibilities  at  each  category 
of  the  scope.  The  two  following  examples  give  possible  ways  that  CEP  could 
be  applied: 

•  The  CE  tackles  an  evolving  medium-size  FoS-based  capability  in  a  few 
months  for  a  specific  mission.  Some  of  these  systems  are  owned  by 
allies.  It  identifies  requirements,  explores  concepts,  develops,  and 
integrates  all  the  systems.  It  takes  into  account  training  and  maintenance 
considerations.  It  does  not  consider  organizational  constraints  and  does 
not  change  any  business  rules  (doctrine,  organization. . .). 

•  Another  CE  context  of  application  is  to  create,  over  a  long  period  of  time 
(5  years),  a  dedicated  SoS.  All  constituents  of  a  capability  are  considered 
as  well  as  all  the  enterprise  levels.  However,  the  process  only  proposes  a 
material  solution  with  a  minor  modification  into  the  organization  if 
required.  The  process  creates  a  transformation  roadmap  that  is  used  as  a 
guide  and  input  for  the  acquisition  activity.  It  is  used  as  a  starting  point 
for  detailed  configuration  item  design  and  other  remaining  phases. 

These  two  examples  imply  different  constraints  and  issues.  Consequently,  it 
is  not  obvious  that  the  CE  could  support  the  creation/evolution  of  these  two 
different  capabilities. 

Ideally,  the  CE  could  cover  the  whole  scope.  However,  a  realistic  approach 
will  be  to  select  only  a  part  of  the  possible  scope  of  CE. 

Figure  16  presents  the  characteristics  or  factors  that  can  influence  the  scope 
and  the  specific  objectives  of  CEP.  Depending  of  the  size  of  a  capability, 
which  constituents  of  a  capability  are  taken  into  account  and  the  timeframe 
allowed  to  upgrade  or  develop  a  capability,  the  CE  specific  objectives  and 
approach  will  not  be  the  same.  The  scope  can  be  extracted  from  the  following 
categories: 

•  Capability  Characteristics:  What  is  included  in  a  capability?  What  are 
its  characteristics?  The  following  points  give  some  characteristics  of  a 
capability  with  many  examples  for  each  of  them. 

Size:  Capability  Area,  Transformational  Capabilities,  Medium-Size 

Capability,  Small-Size  Capability... 

System  Arrangement:  Single  System,  SoS,  FoS... 
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Constituent:  People,  Doctrine,  Techniques,  Tactic  and  Procedures 
(TTPs),  Material,  Organization,  Support,  Training,  or  DOTMLPF  or 
PRICIE. . . 

Enterprise  Level:  Technical,  Business,  both  (fully  or  partially)... 


Characteristic  of  a 
capability  influencing  the 

scope 

►  Size 

►  System  Arrangement 

►  Constituent 

►  Enterprise  Level 


Characteristics  of  the 

CE  inf  luencina  the 

scope 

Role 

Timeframe 

Phases  of  LifeCycle  & 
level  of  completeness 


Characteristic  of  a 
capability  influencing  the 

scope 

♦  Size 

♦  System  Arrangement 

♦  Constituent 

♦  Enterprise  Level 


Figure  16:The  Characteristics  of  a  Current  Capability ,  the  Nature  of  CEP 
and  the  Characteristics  of  a  Future  Capability  Influencing  the  Scope  of  the  CE 

•  Characteristics  to  consider  or  having  an  impact:  What  does  the  CEP 
consider  to  find  the  best  solution?  What  are  the  characteristics  having  an 
impact  of  the  CE?  The  CE  can  take  into  account  only  some 
characteristics  of  the  current  capability  and  some  portion  of  the  life  cycle 
of  the  future  capability.  Examples  are  given  for  each  aspect. 

Phases  of  the  life  cycle  /  Level  of  completeness:  Concept 
Definition,  Detailed  Configuration  Item  Design,  System  Integration, 
Production  &  Manufacturing,  Training,  Deployment,  Operation, 
Maintenance,  Refinement  and  Retirement. . . 

Constituents,  System  Arrangement  and  Enterprise  Level(s):  See 

first  category  for  examples.  CE  can  decide  to  take  into  account  these 
characteristics  partially  to  optimize  its  resources. 

Size:  See  first  category  for  example.  Even  of  this  characteristic  has 
an  impact  on  the  CE,  it  is  out  of  control  of  the  CE. 

•  Applications  to  obtain  a  future  capability:  The  application  category 
contains  all  points  relevant  to  its  application  and  the  effect  of  CE  on  the 
future  capability. 

Role/Task:  Create,  Maintain,  Improve  or  Evolve  (Self-Evolution, 

Joint  Evolution  and  Emergent  Evolution) 

Timeframe:  Short-Term  (Days),  Mid-Term  (Months),  Long-Term 
(Years) 

Phases  of  the  life  cycle  /  Level  of  completeness:  Concept 
Definition,  Detailed  Configuration  Item  Design,  System  Integration, 
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Production  and  Manufacturing. . .  Each  one  completely  or  at  various 
levels  of  completeness. 

Constituents,  Supporting  System(s)  and  Enterprise  Levels:  See 

first  category  for  examples.  CE  can  decide  to  propose  a  capability  in 
regard  of  some  portions  of  its  characteristics. 

Size:  See  first  category 

3.4.3  Process 

A  concept  itself  is  useless  unless  it  can  be  applied.  The  process  is  a  means  by 
which  the  concept  of  CE  is  concretized.  Even  if  the  concept  is  well  defined 
and  scoped,  the  process  can  take  many  forms.  The  four  next  categories  give 
an  idea  of  the  possible  forms  of  CEP: 

•  Methodology:  Spiral,  Iterative,  Incremental,  Waterfall,  Custom,  None 
(Independent  of  the  Methodology),  . . . 

•  Level  of  refinement:  AoA  vs  Pugh  Matrix,  1  vs  20  deliverables,  . . . 

•  Completeness:  What,  When,  Who  (roles),  With  What  (tools),  Entrance 
Criteria,  Exit  Criteria,  Goal  and  Reference(s)  for  each  activity,  Input  and 
Output,  ... 

•  Level  of  adaptability  to  the  organization:  activities  or  deliverables, 
generic  or  tailored  to  an  organization. 

Unlike  the  scope,  all  the  dimensions  of  the  process  can  be  easily  implemented 
in  an  incremental  way.  For  instance,  the  process  can  refine  its  deliverables  (in 
number  or  in  specificity)  gradually  at  each  evolution  without  changing 
previously  works. 

The  CapDEM  project  initially  hypothesized  that  the  solution  would  be  a 
process.  However,  in  the  case  a  global  process  could  not  be  found,  it  will  be 
necessary  to  create  a  process  for  each  application.  A  process  generator  such 
as  a  framework,  guidelines  or  a  meta-process  could  be  the  solution.  It  is  not 
possible  to  commit  to  the  right  solution  without  knowing  better  the  capability 
development  context  and  its  requirements. 

3.4.4  Discussion 

This  section  presented  many  possible  perspectives  of  CEP.  Even  if  they  are 
all  valid  versions  of  CEP,  it  is  not  possible  to  support  and  include  all  these 
technologies  and  scope  for  two  reasons.  Firstly,  it  is  difficult  to  choose  within 
the  scope  and  technologies  until  specific  requirements  of  the  Canadian 
capability  development  community  and  actual  acquisition  problems  are  well 
identified.  Secondly,  the  problem  space  of  the  CE  is  too  large.  An  initial 
solution  will  tackle  only  a  portion  of  the  problem.  The  same  argument  is  also 
valid  for  the  process.  A  complete  process  dictating  everything  of  how  to 
create,  update  or  maintain  a  capability  would  be  ideal.  However,  a 
progressive  development  approach  for  the  process  is  more  appropriate. 
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4.  TP4  CEP  Working  Draft:  A  Theoretical 
Assessment 


This  section  presents  the  analysis  of  the  TP4  CEP  Working  Draft  as  described  to 
TTCP  JSA  TP4  in  the  document  entitled  “Overview  of  the  Capability  Engineering 
Process”  produced  in  June  2003  [75]  and  found  in  Annexe  A.  As  mentioned  in  Section 
2.2,  although  this  document  is  an  overview,  it  was  the  best  source  of  information  the 
CEP  Team  could  find  to  proceed  with  the  analysis. 

The  analysis  is  based  on  two  independent  theoretical  efforts:  an  internal  DRDC  effort 
and  an  industrial  one.  The  DRDC  CEP  Team  members  performed  the  first  one  during 
a  two-days  workshop  held  in  Valcartier.  Before  this  workshop,  the  CEP  Team 
members  read  several  documents  about  acquisition  and  CBP.  Some  were  directly 
referred  in  the  above-mentioned  TP4  CEP  Working  Draft  document.  The  workshop’s 
main  objective  was  to  achieve  a  consensus  about  strengths  and  limitations  of  the 
proposed  process.  Mr  Jocelyn  Leclerc,  a  consultant  having  experience  in  different 
contexts,  conducted  the  other  effort  in  order  to  provide  an  industrial  point  of  view.  The 
consultant  delivered  a  document  entitled:  ChEng  Capability  Engineering  Process 
Assessment  Report  [58]  referred  as  the  CGI  Analysis  report  in  the  following.  After 
conducting  these  two  efforts,  a  meeting  was  organised  with  the  author  of  the  TP4  CEP 
Working  Draft  document  (Schmidt)  in  order  to  confirm  and  get  additional  information. 

The  following  sections  present  the  consolidated  results  of  these  efforts.  The  strengths 
and  limitations  are  described.  The  recent  meeting  with  Schmidt  modified  or  reinforced 
our  understanding  of  some  strengths  and  limitations.  In  such  cases,  clarifications  are 
reported  in  a  box.  This  chapter  concludes  with  comments  about  the  TP4  CEP  Working 
Draft  according  to  our  current  understanding. 

4.1  Strengths 

The  strengths  presented  in  this  section  are  related  to  the  process  approach,  references, 
deliverable,  metrics  and  modeling.  They  describe  rather  high-level  observations. 

4.1 .1  Standard  Approach 

The  process  follows  a  standard  and  commonsense  approach  similar  to 
Enterprise  Architecture  processes  and  TOGAF.  It  starts  with  the  “as-is” 
definition,  defines  a  long-term  vision,  assesses  different  options,  chooses  the 
best  one  in  order  to  achieve  the  vision  with  respect  to  constraints  and  define 
required  investments.  Finally,  the  selected  solution  can  be  divided  into 
incremental  steps. 

The  process  considers  some  elements  of  the  DOTMLPF:  Doctrine, 
Organisation,  and  Material.  In  addition,  it  takes  into  account  tactics  elements. 
The  process  is  generic  and  described  very  high-level  activities  allowing 
adaptation  to  particular  contexts. 


The  process  is  capable  of  addressing  DOTMPF  elements.  The  L  - 
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Leadership  and  Education  piece  is  not  completely  addressed.  The  process 
is  the  combination  of  Enterprise  Architecture  concepts  and  the  System 
Acquisition  Process.  Within  each  domain,  the  SysEng  process  provides  the 
basis  for  decomposing  the  complexity  of  the  problem,  and  to  enable 
assessments,  analysis,  and  trade-offs  among  alternative  solutions. 


4.1.2  Known  References 

The  process  is  the  combination  of  DoD  Acquisition  Policies  and  Key 
Enterprise  Architecture  concepts.  These  were  combined  by  the  author  to 
produce  a  more  comprehensive  framework  for  developing  and  assessing 
“Architectures”  to  support  Enterprise  Investment  Decisions.  The  process 
refers  to  different  well-known  standards  and  documents:  US  DoD  Directive 
5000.1  and  DoD  Instruction  5000.2.  The  IEEE  1220  is  not  explicitly 
mentioned  but  some  activities  are  inspired  from  it.  The  process  proposes 
some  deliverables  following  DoD  AF  format. 

4.1.3  Transformation  Roadmap  Definition 

The  content  of  the  final  deliverable  is  well  defined.  Each  activity  of  the 
Section  2.4  [75],  Establish  the  Transformation  Roadmap,  describes  a  specific 
section  of  the  final  deliverable. 

4.1.4  Metrics  Consideration 

The  process  suggests  the  identification  of  measures  of  effectiveness  to 
evaluate  performance,  efficiency,  effectiveness  and  resource  utilization. 

4.1.5  Model-Driven 

The  process  requires  the  development  of  operational  and  physical  models. 
Our  assumption  in  the  context  of  the  process  was  that  models  could  be 
simulated.  This  fact  means  that  models  provide  a  basis  for  assessment  and 
engineering  analysis  and  to  enable  trade-offs  among  alternative  solutions. 


The  author  confirmed  that  his  definition  of  a  view  is  a  static  representation 
while  a  model  is  a  dynamic  one  that  is  executable. 


4.2  Limitations 

The  limitations  presented  in  this  subsection  concern  process  scope,  activities,  figures 
and  definitions.  In  opposition  to  the  strength  presented  in  Subsection  4.1,  they  are 
more  specific  observations. 

4.2.1  US  Specificity 

This  process  has  been  developed  to  address  the  US  acquisition  problem 
space,  specifically  from  a  US  Navy  perspective.  It  is  not  necessarily 
applicable  to  the  specificities  of  DND/CF’s  acquisition  process.  Some  work  is 
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required  to  better  understand  unique  and  common  elements  of  the  US 
approach. 

4.2.2  Overall  Schematic  View 

An  overall  schematic  view  is  missing  in  order  to  visualize  the  sequence  and 
the  parallelism  of  the  activities.  This  would  facilitate  the  understanding  of  the 
existing  schemas  and  provide  an  overview  of  all  activities  involved  in  the 
process. 


4.2.3  Scope  and  Intention 

The  process  description  is  more  at  the  management  level  than  at  the  SysEng 
level.  In  addition,  the  capability  concept  is  not  sufficiently  addressed. 


Schmidt  explained  that  the  TP4  CEP  Working  Draft  addresses  mainly  the 
capability  management  level  as  shown  in  Figure  17.  Schmidt  suggests  building 
the  CEP  from  the  IEEE  1220.  It  can  be  applied  at  all  levels  of  Organization,  for 
mid  to  long  term  planning,  and  across  Service,  Joint  Service  and  Allied/Coalition 
endeavours.  For  that  reason,  it  was  discussed  as  something  to  be  explored  by  the 
TTCP  JSA  TP4  Committee. 


Addressed  by 
TP4  CEP 
Working  Draft 


Should  be 
addressed  by 
IEEE  1220 
adapted  to  CE 


Figure  1 7:  Process  Scope 


4.2.4  Boundary  and  Context 

The  process  is  missing  an  initial  activity  to  define  the  boundary  and  context 
of  the  capability.  Best  practices  suggest  starting  a  system  development  by 
identifying  its  boundaries  and  understand  its  environment. 
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4.2.5  Activity  Description 

The  level  of  details  of  activity  descriptions  varies  a  lot.  For  example,  the 
activities  in  Section  2.4  [75]  describe  the  content  of  each  section  of  the 
deliverable  “Transformation  Roadmap”  while  others  mention  only  the  type  or 
title  of  the  output  without  any  details  of  the  content.  For  instance,  each 
activity  description  could  include  the  following  information: 

•  Goal  and  objectives:  What  are  the  goal  and  the  objectives?  How  deep 
does  CEP  Team  have  to  go  to  achieve  the  objectives? 

•  When:  When  could  this  activity  be  performed?  Can  it  be  done 
concurrently  to  another? 

•  Input:  Which  information  is  needed  to  achieve  the  activity?  What  is  the 
format  of  each  input? 

•  Output:  What  are  the  deliverables  to  produce,  their  format?  Are  template 
descriptions  and  examples  of  the  output  available? 

•  How:  How  is  it  executed?  What  tools  can  help  performing  the  activity? 
How  to  share  information  among  the  people  involved  in  this  activity? 

•  Who:  Who  is  involved  in  this  activity?  What  are  the  roles  and 
responsibilities  of  the  participants?  What  kind  of  expertise  and 
knowledge  is  required  for  each  role? 

4.2.6  Requirements  Management 

The  requirements  and  user  expectations  management  is  partially  addressed. 
According  to  SysEng  guidelines,  an  iterative  process  of  validation  is 
preferred. 


The  requirements  are  handled  at  the  previous  stage:  Operations  Analysis. 
This  supplies  the  set  of  requirements  necessary  to  start  the  CEP.  Those 
requirements  address  the  material  part  of  DOTMLPF. 


4.2.7  CEP  Figure 

The  title  of  the  first  figure  in  [75]  is  misleading.  The  figure  shows  the 
Capability-based  System  acquisition  process  while  the  title  “Capability 
Engineering  Process”  refers  only  to  the  two  first  phases  in  the  Capability- 
based  System  acquisition  process. 

Based  on  the  evolutionary  acquisition  process,  the  increments  should  be  risk 
driven.  The  number  and  scope  of  delivery  increments  may  vary  according  to 
anticipated  risks.  In  order  to  emphasize  this  fact  to  the  reader,  the  first  figure 
of  the  document  should  show  an  undetermined  number  of  increments  instead 
of  three. 

Some  of  the  important  concepts  introduced  in  Figure  1  of  the  document  do 
not  appear  in  the  Process  description  provided  in  the  document  (see  Annexe 
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A).  These  concepts  are:  “Warfare  Capability  Analysis”,  “Capability  Vision” 
and  “Portfolio  Investment  Analysis”. 


Schmidt  confirmed  that  the  title  was  inappropriate.  The  figure  should  look  as  in 
Figure  18.  This  figure  also  shows  three  blocks  but  it  should  be  modified  to  N 
increments  in  order  to  conform  to  the  risk  driven  approach. 


■Capability  Engineering  Process 


l(Current) 

Architecture 


Capability 

Vision 


Transformation 
Roadinap  — 


“As- Is”  Architecture 
“Vision”  Architecture 
Transformation  Roadmap 


Operational 

Capability 


Incremental 

Operational 

Capability 


^  Initial 
Operational 
Capability 


Figure  18:  Capability-Based  System  Acquisition  Process 


4.2.8  Glossary  References  and  Definition 

A  glossary,  a  list  of  references  and  a  definition  sections  are  missing.  Although 
the  terms  are  known,  they  have  different  meaning  for  different  authors.  To 
provide  a  common  understanding,  important  concepts  need  to  be  defined  e.g. 
model,  view,  business  process,  functional  model,  operational  view, 
capabilities  objectives,  strategic  vision,  value-added. 

4.3  Qualitative  assessment 

This  subsection  presents  a  qualitative  assessment  of  the  TP4  CEP  Working  Draft  in 
Table  1.  It  summarises  well  the  current  thoughts  of  the  CEP  Team  about  this 
document.  The  criteria  used  were  proposed  in  the  CGI  Analysis  report.  For  each  of  the 
criterion,  an  appreciation  is  expressed  through  a  short  comment,  according  to  the 
understanding  of  the  process  and  the  context  when  the  assessment  was  conducted. 
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Table  1:  Qualitative  Assessment 


QUALITY 

DESCRIPTION 

COMMENTS 

Relevance 

This  criterion  measures  Process’ 
applicability  to  DND/CF  specific  context. 

A  DND/CF  problematic  understanding  is 
missing  to  properly  address  this  criterion. 

Compliance 
to  Standards 

This  criterion  measures  Process’ 
adherence  to  Military  Standards  in  the 
areas  of  SysEng,  Enterprise 

Architecture  and  Military  Acquisition. 

The  process  refers  to  5000.1, 5000.2  and 
suggests  DoD  AF  deliverables. 

Functional 

Quality 

This  criterion  measures  Process’  quality 
with  regard  to  the  richness  and 
completeness  of  the  functions  it  offers  to 
address  and  solve  the  process  at  hand 
(i.e.  Capability-Based  Military 

Acquisition). 

The  following  limitations  were  identified: 
Activity  Descriptions,  Requirements 
Management,  Boundary  and  Context. 

Technical 

Quality 

This  criterion  measures  Process’  quality 
with  regard  to  its  technical  elements 
such  as  its  toolset,  technical 
infrastructure,  etc. 

As  mentioned  in  the  Activity  Description 
limitation,  there  are  no  references  to 
toolsets  or  technical  infrastructures. 

Effectiveness 

This  criterion  measures  Process’  ability 
to  meet  predetermined  objectives. 

The  process  has  not  been  completely 
applied  yet.  The  JIIFC  application  is  still 
in  progress. 

Efficiency 

This  criterion  measures  Process’  ability 
to  minimize  resource  usage  while 
meeting  predetermined  objectives. 

As  identified  in  Section  4.2,  activity 
descriptions  do  not  specify  who  is 
performing  the  activity. 

Usability 

This  criterion  measures  Process’ 
learning  curve,  ease  of  implementation, 
and  ease  of  use. 

The  following  limitations  were  identified: 
Overall  Schematic  View,  Activity 

Description  and  Glossary,  References 
and  Definition. 

Impact 

This  criterion  measures  Process’ 
impacts  on  current  DND/CF 

Organization,  methods,  procedures  and 
tools. 

A  DND/CF  problematic  understanding  is 
missing  to  properly  address  this  criterion. 

Maturity 

This  criterion  measures  Process’  level  of 
progress  currently  achieved  with  regard 
to  demonstrated  capability  in  the  area  of 
Military  Acquisition. 

The  process  is  a  draft  document  and  is 
under  definition. 

Continuity 

This  criterion  measures  the  long-term 
commitment  of  the  sponsoring 
organizations  with  regard  to  support  and 
evolution  of  the  process. 

It  is  too  early  to  assess  this  criterion. 

Cost 

This  criterion  measures  Process’  direct 
and  indirect  resources  that  are  required 
for  its  acquisition,  implementation  and 
use. 

A  DND/CF  problematic  understanding  is 
missing  to  properly  address  this  criterion. 

In  addition,  as  mentioned  in  the  Activity 
Description  limitation,  there  is  no 
indication  about  who  is  conducting  the 
activities. 
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4.4  Applicability 

The  TP4  CEP  Working  Draft  in  its  current  overview  version  is  not  applicable  by  itself. 
Many  elements,  steps  and  outputs  are  not  clear  enough  to  be  useable.  The  user  has 
room  for  a  lot  of  interpretation,  which  could  lead  to  different  implementations  for  the 
same  kind  of  problem.  The  targeted  process  should  be  self-understanding  and  self- 
applicable  to  avoid  such  interpretations.  The  process  should  allow  to  re-use  models 
and  data  enabling  leveraging  between  capabilities. 

Considering  the  limitations,  the  Transformation  Roadmap  may  not  provide  all 
adequate  information  to  support  strategic  investment  decisions  for  DND/CF  capability 
implementation. 
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5.  TP4  CEP  Working  Draft:  A  Practical  Assessment 
through  JIIFC  Case  Study 

The  JIIFC  case  study  aimed  at  learning  from  the  TP4  CEP  Working  Draft,  its  CEE, 
and  the  associated  body  of  knowledge.  This  case  study  applied  the  TP4  CEP  Working 
Draft  based  on  Schmidt’s  documentation  and  used  the  CEE  toolset  to  support  JIIFC 
concept  definition  activities.  Lessons-learned  are  being  captured  as  the  activities  in 
JIIFC  continue.  From  August  to  November  2003,  CEP  Team  focused  its  activities  on 
context/boundary  definition,  requirements  analysis,  and  modelling  a  subset  of  the 
current  environment.  In  this  section  a  preliminary  assessment  of  the  TP4  CEP 
Working  Draft  based  on  these  activities  is  presented.  Table  2  summarises  which 
activities  of  the  TP4  CEP  Working  Draft  were  partially  or  totally  addressed  within  this 
effort. 

Table  2:  TP4  CEP  Working  Draft  Activities  Addressed  with  the  JIIFC  Case  Study  (2003) 


TP4  CEP  Working  Draft  Activities 

Performed 
for  JIIFC 
(2003) 

1  Define  the  “as-is”  Integrated  Architecture 

1.1  Capture  the  “as-is”  Operational  Model 

Total 

1.2  Capture  the  “as-is”  Physical  Model 

Total 

1 .3  Identify  the  Measures  of  Effectiveness 

Partial 

1 .4  Identify  Areas  of  Opportunitv  for  Improvement 

Partial 

2  Establish  the  Strategic  Vision 

2.1  Evaluate  Availability  of  Technology 

Partial 

2.2  Evaluate  Doctrine  &  Tactic  Evolution 

Partial 

2.3  Evaluate  Force  Structure  Evolution 

Partial 

2.4  Document  the  Strategic  Vision 

N/A 

3  Develop  the  "Vision"  Integrated  Architecture 

3.1  Identify  Candidate  "Vision"  Architecture  Alternatives 

Partial 

3.2  Evaluate  Candidate  Alternatives  for  Feasibility 

Partial 

3.3  Select  Alternative(s)  for  Concept  Development 

Partial 

4  Establish  the  Transformation  Roadmap 

4.1  Identify  the  Organizational  (Force)  Structure  Evolution  Plan 

N/A 

4.2  Establish  Capability  Evolution  Objectives 

N/A 
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4.3  Establish  The  Evolutionary  Acquisition  Roadmap  (Risk  Mitigation) 

N/A 

4.4  Establish  the  Force  Training  &  Transition  Plan 

N/A 

4.5  Establish  the  Investment  Plan 

N/A 

As  a  CapDEM  activity,  the  scope  of  this  case  study  focuses  mainly  on  the  application 
and  analysis  of  the  TP4  CEP  Working  Draft  and  the  associated  toolset.  Nonetheless, 
the  CEP  Team  works  together  with  the  JIIFC  project  team  to  ensure  the  work  being 
carried  out  meets  the  objectives  and  requirements  of  both  the  CapDEM  and  the  JIIFC 
projects. 

5.1  The  JIIFC  Project 

The  JIIFC  project  supports  the  departmental  vision  to  provide  decision-makers  with 
the  timely  and  relevant  fused  information  needed  to  command  and  control  CF 
operations  whenever  and  wherever  they  take  place  around  the  world.  The  mission  of 
JIIFC  is  to  deliver  an  integrated  situation  awareness  capability  that  supports  all  levels 
of  command.  Detail  description  of  the  project  can  be  found  in  the  JIIFC  Concept  of 
Operations  (ConOps)  [50]  and  the  Statement  of  Operational  Requirements  (SOR)  [51]. 

Currently,  JIIFC  is  in  its  definition  phase  to  further  develop  the  concept  of  a  joint 
fusion  capability  to  support  strategic  level  command  and  control.  The  first  versions  of 
ConOps  and  SOR  have  been  developed  before  CapDEM’ s  participation.  These  two 
documents  serve  as  valuable  input  to  the  JIIFC  concept  definition  process.  The  main 
expected  outputs  from  the  JIIFC  concept  definition  process  are  two  well  defined 
ConOps  and  SOR  documents  to  support  acquisition.  The  definition  phase  will  be 
facilitated  by  Modelling  and  Simulation  (M&S)  coupled  with  requirements 
traceability. 

5.2  The  JIIFC  Concept  Definition  Process 

The  JIIFC  concept  definition  process  is  adapted  from  the  Schmidt  description  of  the 
TP4  CEP  Working  Draft,  the  IEEE  1220  [44],  and  the  IEEE  1362  [45].  The  TP4  CEP 
Working  Draft  provides  a  high  level  description  of  the  planning  and  engineering 
activities,  while  the  two  IEEE  publications  serve  as  guidelines  for  detail  activities  and 
contents  of  outputs  throughout  the  process.  Following  accepted  standards  ensures  that 
the  concept  definition  process  (from  here  on  referred  to  as  the  JIIFC  Process)  does  not 
deviate  from  mature  engineering  methodology. 

Figure  19  is  an  overview  of  the  JIIFC  Process  presented  as  an  Enhanced  Functional 
Flow  Block  Diagram  (EFFBD)  produced  using  CORE.  The  notations  of  EFFBD  are 
very  simple:  boxes  are  activities,  incoming  arrows  are  inputs,  and  outgoing  arrows  are 
outputs.  The  circles  labelled  LP  represent  LooP-backs,  denoting  the  iterative  nature  of 
the  process. 

Although  the  process  presented  in  the  diagram  is  a  linear  process,  some  activities  are 
being  carried  out  in  parallel,  or  overlapping  one  onto  the  other.  However,  the  degree  of 
parallelism  and  overlapping  depend  on  the  availability  of  information.  For  instance, 
the  ConOps  and  SOR  already  captured  much  information  needed  to  support  both 
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operational  analysis  and  modeling  of  “as-is”  environment,  these  two  steps  were  being 
carried  out  in  parallel.  The  following  paragraphs  describe  the  process  activities  as 
depicted  in  the  EFFBD  in  the  following  paragraphs. 

5.2.1  Operational  Analysis  as  a  Trigger 

Operational  analysis  is  the  effort  to  identify  high-value  systems  concepts  and 
their  enabling  technologies  in  a  way  that  is  objective,  traceable  and  robust 
[49].  Typically,  operational  analysis  is  a  strategic  enterprise-level  activity  that 
leads  to  the  identification  of  multiple  new  capabilities.  The  collection  of 
related  capabilities  is  usually  described  as  a  Capstone  ConOps,  which 
becomes  the  guidance  document  for  integrated  lower  level  capabilities.  For 
instance,  a  C4ISR  Operations  Analysis  would  lead  to  a  C4ISR  Capstone 
ConOps,  which  would  identify  mission  need,  operational  concepts  and 
relationships  for  JIIFC  in  the  context  of  the  Capstone  ConOps.  Within  the 
C4ISR  Campaign  Plan  [6],  JIIFC  represents  a  single  capability  to  provide 
joint  intelligence  support  to  operations.  The  C4ISR  Campaign  Plan  is  one  of 
the  key  documents  used  to  define  the  context  of  JIIFC. 
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Figure  19:  JIIFC  Concept  Definition  Process 
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5.2.2  Activity  1 :  Define  Context  and  Boundary 

A  system’s  context  is  a  set  of  entities  that  can  impact  the  system  but  not  be 
impacted  by  the  system.  These  entities  impact  the  system  through  their  inputs 
and  constraints,  as  well  as  the  outputs  of  the  system  must  produce  to  satisfy 
the  external  entities.  The  boundary  of  the  system  is  defined  by  the 
characteristics  of  these  inputs,  constraints  and  outputs  of  external  entities. 
Unlike  in  system  development  phase,  in  the  system  concept  definition  phase, 
the  context  and  boundary  are  subjects  of  study  and  it  is  conceivable  that  the 
context  and  boundary  may  be  changed  to  support  a  viable  concept  for  the 
system. 

JIIFC  is  an  intelligence  capability  that  feeds  into  situation  awareness,  which 
supports  of  command  and  control  functions.  JIIFC,  being  a  joint  intelligence 
entity,  also  needs  to  interface  with  many  existing  intelligence  units  in  the 
Army,  Navy,  Air  Force  and  other  government  departments.  All  these  entities 
together  form  the  context  of  JIIFC.  The  activities  related  to  identifying  these 
entities  and  describing  the  interaction  between  them  and  JIIFC  will  establish 
the  context  and  system  boundary. 

5.2.3  Activity  2:  Analyze  Requirements 

The  purpose  of  requirements  analysis  is  to  construct  operational  requirements 
derived  from  operational  concepts  and  to  validate  the  requirements  through 
analysis  to  ensure  that  operational  concepts  are  faithfully  translated  into 
operational  requirements.  Requirements  analysis  tools  enable  concepts  and 
requirements  to  be  represented  as  individual  objects  in  models  and  to 
establish  traceability  between  them.  Traceability  is  the  feature  that  establishes 
links  between  concepts  and  requirements  to  ensure  that  all  operational 
concepts  have  been  translated  into  operational  requirements,  and  that  all 
operational  requirements  are  supported  by  operational  concepts.  Traceability 
also  provides  an  indication  of  the  impact  of  changing  either  operational 
concepts  or  requirements.  When  cost  elements  are  attached  to  requirements, 
cost  impact  of  requirements  and  of  changes  in  requirements  can  be  more 
easily  evaluated. 

According  to  IEEE  1220,  requirements  analysis  can  be  performed  more 
efficiently  when  requirements  are  grouped  according  to  their  types: 
functional,  operational  and  design.  Figure  20  shows  the  current  requirements 
schema  for  JIIFC. 

Another  aspect  of  requirements  analysis  is  to  identify  parameters  and  metrics 
needed  to  validate  concepts  and  requirements.  Key  Performance  Parameters 
(KPPs)  are  the  important  operational  capabilities  to  be  implemented  and  the 
expected  performance  measures  that  affect  the  decision  to  invest.  The 
Measures  Of  Effectiveness  (MOE)  define,  in  quantitative  terms,  how  the 
architecture  is  to  be  evaluated  on  performance,  efficiency,  effectiveness  and 
resource  utilization.  The  challenge  is  to  define  capability  metrics  that  allows 
us  to  evaluate  a  system’s  contribution  to  capability  requirements.  Some 
suggestions  on  capability  metric  are  force  readiness,  which  can  be 
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decomposed  into  many  more  quantifiable  measures. 


Figure  20:  JIIFC  Requirements  Schema 

5.2.4  Activity  3:  Model  Current  Environment 

Modelling  the  current  environment  creates  a  baseline  to  support  operational 
analysis  through  identifying  areas  for  improvement,  the  KPPs,  and 
corresponding  MOE.  Simulation  of  the  operational  and  functional  models  can 
provide  an  inexpensive  and  early  indication  of  MOE  to  validate  operational 
concepts  and  requirements  prior  to  design  and  implementation  of  system 
components.  These  metrics  often  suggest  options  or  alternatives  that  had  not 
been  identified  prior  to  the  modelling  activity. 

According  to  Schmidt  [75],  the  “as-is”  environment  is  represented  by  an 
operational  model  and  a  physical  model  of  the  existing  system  (referred  to  by 
Schmidt  as  the  “as-is”  Integrated  Architecture).  The  operational  model 
identifies  the  organizational  structure,  the  activities  performed  by  each 
elements  of  the  organization,  the  information  exchanged  among  the 
participating  organizations,  and  the  resources  required  to  execute  the  business 
process.  The  physical  model  captures  information  related  to  the  arrangement 
of  existing  facilities/platforms,  systems,  operators  and  interfaces.  This 
establishes  the  linkages  necessary  to  identify  how  organizational  personnel 
utilize  systems  to  execute  the  activities  and  accomplish  the  business  processes 
defined  in  the  operational  model. 

JIIFC  is  a  new  conceptual  capability;  and  there  exist  no  “as-is”  environment 
for  a  joint  intelligence  capability.  One  alternative  is  to  model  the  existing 
disparate  intelligence  community  as  a  current  environment  for  baseline 
comparison.  Another  alternative  is  to  model  the  existing  risk  mitigation 
laboratory  configuration  as  the  current  environment.  Some  believe  the  former 
does  not  represent  a  fair  baseline  for  performance  comparison  because  JIIFC 
operates  on  a  new  concept.  Yet,  the  latter  poses  some  challenges  in  using  “as- 
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is”  environment  to  identify  KPPs,  and  related  metrics,  and  areas  for 
improvement  since  the  lab  setting  is  not  yet  operational  and  no  data  can  be 
collected  based  on  the  past  operational  experience.  As  a  result,  the  second 
alternative  will  rely  heavily  on  the  inputs  from  subject  matter  experts  and 
simulation  to  provide  necessary  data  to  support  both  operational  analysis  as 
well  as  the  gap  analysis  between  “as-is”  and  future  requirements.  This  could 
also  be  augmented  by  the  use  of  the  ConOps  and  SOR  to  identify  KPPs  and 
to  establish  threshold  (minimum  acceptable)  performance  values  and 
objective  (goals  for  achievement)  values  for  those  KPPs  and  then  develop 
through  analysis  MOE  for  the  KPPs.  The  choice  of  “as-is”  environment  will 
be  determined  in  the  next  wave  of  activities. 

5.2.5  Activity  4:  Analyse  Gaps 

Gap  analysis  refers  to  the  activities  undertaken  to  identify  the  areas  of 
significant  differences  between  the  existing  capabilities  and  the  future 
capabilities.  The  KPPs  and  MOE  identified  in  the  “as-is”  environment  are 
compared  to  those  specified  in  the  SOR.  This  will  help  to  further  define  areas 
for  improvements,  understand  the  size  of  the  gaps  and  establish  initial 
thoughts  on  possible  improvement  approaches.  The  SOR  should  be  use  to 
establish  priority  for  these  improvements. 

5.2.6  Activity  5:  Evaluate  Alternatives 

The  goal  of  this  activity  is  to  evaluate  the  strengths  and  weaknesses  of 
various  alternatives  to  provide  needed  capability.  The  SysEng  process 
provides  guidance  to  evaluate  alternatives  by  means  of  trade  studies, 
assessing  risks  and  cost/benefit  of  various  options.  The  MOE  identified 
earlier  will  be  the  parameters  for  comparison. 

Simulation  plays  an  important  role  in  this  step.  If  carried  out  correctly,  it 
could  save  both  time  and  money  during  concept  definition.  In  some  cases, 
simulation  may  be  the  only  way  to  evaluate  a  concept  without  a  huge 
investment  in  resources. 

The  JIIFC  Process  recognises  the  value  of  simulation  to  analyse  and  validate 
alternatives.  In  this  use  case  the  CEP  Team  have  demonstrated  various 
simulation  tools  in  support  of  these  analyses.  For  instance,  the  use  of 
COREsim  [85]  to  simulate  resource  utilization  so  as  to  identify  process 
bottlenecks;  the  use  of  Integrated  Performance  Modeling  Environment 
(IPME)  [62]  to  estimate  human  resource  requirements  based  on  attributes 
related  to  human  performance;  and  the  use  of  OpNet  [69]  to  model  and 
simulate  network  requirements  and  equipment  costing. 

5.2.7  Activity  6:  Select  Future  Architecture  for  Implementation 

The  stakeholders  are  responsible  for  the  selection  of  the  future  architecture. 
However,  the  selection  will  be  made  easier  by  the  accompanying  information 
generated  during  the  whole  process.  With  traceability  implemented, 
stakeholders  will  be  able  to  assess  options  more  informatively  by  following 
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the  linkages  to  trade  study  reports,  engineering  data  and  supporting 
documents. 

5.3  The  JIIFC  Engineering  Environment 

The  existing  JIIFC  engineering  environment  provides  essential  technology  to  support 
the  execution  of  the  process.  An  integrated  engineering  repository  (such  as  that 
provided  in  Interchange  and  CORE)  serves  as  a  central  repository  for  all  data  and 
information  generated  from  various  activities  performed  by  different  domain  experts. 
The  CEP  Team  are  currently  evaluating  both  options  for  the  final  JIIFC  integrated 
engineering  repository. 

Presently,  the  JIIFC  Engineering  Environment  consists  of  the  basic  NCEE  COTS 
software,  i.e.  DOORS,  CORE,  Rational  Rose  [43]  and  Interchange,  and  a  few  tools  to 
support  domain  specific  analysis  and  simulation  (as  shown  in  Figure  16).  Note  that 
some  of  the  linkage  or  plug-ins  between  tools  and  the  central  repository  are  still  under 
development  (represented  by  dotted  lines).  IPME  is  a  human-systems  integration  tool 
for  modelling  the  workload  and  workspace  for  JIIFC.  The  link  to  address 
interoperability  issues  refers  to  the  need  to  integrate  engineering  data  from  related 
projects  into  the  JIIFC  environment  to  ensure  future  interoperability  in  a  C4ISR 
environment.  Some  of  this  engineering  data  include  architecture  models  in  the  Defence 
Enterprise  Architecture  (DEA),  and  other  C4ISR  projects.  These  datasets  have  been 
created  by  different  tools  and  the  JIIFC  engineering  team  will  determine  the  need  for 
the  development  of  custom  links  or  plug-ins  into  the  integrated  engineering  database. 
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Figure  21:  JIIFC  Integrated  Engineering  Environment 


DRDC  Valcartier  TR  2004-230 


47 


5.4  Lessons  learned 


5.4.1  Results  from  the  JIIFC  Workshop 

The  JIIFC  Case  Study  began  in  June  2003.  On  completion  of  the  initial 
modelling  work,  a  workshop  was  held  in  October  2003  to  solicit  feedback 
from  the  JIIFC  Project  Team  on  the  value  of  the  activities  performed  during 
the  four-month  period.  The  workshop  had  four  sessions:  requirements 
analysis,  functional  modelling,  trade  study  on  human  factor  engineering,  and 
trade  studies  in  costing  and  computer  network  modelling.  Each  session 
consisted  of  a  presentation  on  the  engineering  activities  in  the  domain  area, 
and  a  feedback  period  in  which  the  participants  answer  a  set  of  questions 
related  to  the  CEP. 

In  the  requirements  analysis  session,  the  CEP  Team  demonstrated  the 
concepts  of  gap  analysis  and  traceability  using  the  information  from  the 
ConOps  and  SOR.  We  also  presented  some  analysis  results,  such  as  dangling 
requirements,  to  the  participants  to  illustrate  the  main  benefits  of 
requirements  analysis.  In  the  functional  modelling  session,  the  CEP  Team 
presented  the  Task,  Process,  Exploitation,  Dissemination  (TPED)  process 
model  and  illustrated  the  use  of  a  simulation  tool  (COREsim)  to  analyse 
resources  utilization  and  optimization  of  processes.  In  the  human  factor 
engineering  session,  we  modelled  the  application  of  the  TPED  process  in  a 
scenario  that  involves  open  source  intelligence  analysis.  Using  this  scenario, 
human  factor  engineers  were  able  to  demonstrate  realistically  the  type  of 
analyses  they  could  perform  using  IPME  to  provide  values  to  JIIFC.  In  the 
costing  trade  study  and  computer  network  modelling  session,  we  have 
identified  areas  that  cost  analysis  will  provide  benefits  to  JIIFC  concept 
definition,  and  the  use  of  OpNet  to  support  network  M&S. 

In  short,  the  members  of  the  JIIFC  team  provided  many  constructive 
comments  throughout  the  workshop.  At  the  end  of  the  workshop,  the  CEP 
Team  solicited  the  participants’  overall  acceptance  of  the  CapDEM  approach. 
The  response  revealed  a  strong  support  for  the  JIIFC  Process  used  in  JIIFC 
case  study. 

5.4.2  The  Application  of  TP4  CEP  Working  Draft 

In  the  JIIFC  Case  Study,  the  CEP  Team  was  able  to  adapt  the  TP4  CEP 
Working  Draft  to  support  JIIFC  concept  definition  activities.  Initially,  we 
expected  the  TP4  CEP  Working  Draft  to  be  a  well-developed  process.  The 
CEP  Team  soon  realized  that  the  TP4  CEP  Working  Draft  is  still  evolving. 
Nonetheless,  the  high  level  description  of  the  processes  served  well  as  the 
framework  to  adapt  to  the  needs  of  the  JIIFC  project.  The  lack  of  details  in 
the  TP4  CEP  Working  Draft  document  also  provided  us  the  freedom  to  adapt 
the  process  to  address  specific  areas  of  focus  for  JIIFC. 

Although  the  TP4  CEP  Working  Draft  documentation  lacked  details,  it  is 
built  from  the  IEEE  1220  standard  for  SysEng  process  and  the  DoD  AF. 

IEEE  1220  provides  a  very  detailed  description  of  a  SysEng  process  that 
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supports  engineering  for  the  SLC.  The  DoD  AF  and  its  architecture  data 
model  (CADM)  enforce  the  architecture  approach  to  ensure  interoperability. 
These  two  documents  serve  as  the  foundation  documents  for  development  of 
the  JIIFC  Process. 

In  this  case  study,  our  objective  is  to  apply  the  process  to  support  concept 
definition  activities.  A  review  of  the  IEEE  1220  indicated  that  the  SysEng 
process  begins  at  system  development.  Quoting  from  IEEE  1220: 

“The  SysEng  process  applies  throughout  the  SLC  to  all  activities  associated 
with  product  development,  test,  manufacturing,  training,  operation,  support 
distribution,  disposal  and  human  SysEng.”  Although  the  document  addresses 
system  definition,  the  focus  is  on  “  [defining]  system  products  required  to 
satisfy  operational  requirements.” 

In  concept  definition,  the  focus  is  on  providing  a  structured  approach  for 
users  to  explore  possible  solution  strategies  to  a  problem  by  assessing  their 
feasibility,  utilities,  and  identifying  the  limitations,  constraints  and  risks.  For 
IEEE  1220,  the  outcome  is  a  well-designed  system.  For  concept  definition  the 
outcome  is  a  well-defined  ConOps  and  operational  requirements  documents. 
This  is  not  to  say  that  IEEE  1220  is  not  useful  to  concept  definition. 
Contrarily,  the  CEP  Team  realised  that  with  a  shift  of  focus,  many  of  the 
activities  still  apply.  In  fact,  in  order  to  be  able  to  validate  a  concept,  we  need 
to  perform  systems  design  and  development  to  an  extent  that  will  provide 
enough  understanding  of  the  characteristics  of  a  potential  solution  (e.g. 
system  prototyping). 

The  emphasis  on  concurrent  engineering  of  SLC  is  key  to  SysEng.  It  applies 
to  concept  definition  as  much  as  to  SysEng.  Consequently,  trade  studies  in 
resource  requirements,  costing  and  technology  forecast  for  the  SLC  are 
crucial  in  validating  a  concept.  The  challenge  of  life  cycle  management 
becomes  enormous  in  CE  because  capability  is  almost  always  supported  by  a 
SoS  and  the  life  cycle  of  these  individual  systems  must  be  managed  to 
maintain  desired  capability.  Having  a  well-defined  process  that  is  adopted  by 
all  systems  owners  is  a  starting  point.  A  well-designed  integrated  engineering 
environment,  such  as  the  NCEE,  will  be  a  technological  enabler. 

The  US  NCEE  provided  the  JIIFC  case  study  with  an  initial  set  up  for  an 
integrated  engineering  environment.  The  environment  allows  us  to  implement 
traceability  across  all  engineering  data  and  information.  CEP  Team  gained 
appreciation  of  such  an  environment  as  we  explore  the  context  for,  and  the 
makeup  of  JIIFC.  The  large  number  of  stove-pipe  systems  that  JIIFC  must 
integrate  to  provide  joint  fusion  capability  will  require  considerable 
engineering  and  management  effort.  We  believe  the  integrated  engineering 
environment  is  essential  to  support  engineering  and  management  of  concept 
definition  as  well  as  system  design  and  development. 

Initial  Process  Assessment  based  on  JIIFC  case  study 

Using  the  experience  from  the  JIIFC  case  study,  the  CEP  Team  was  able  to 
provide  a  preliminary  assessment  of  the  TP4  CEP  Working  Draft  using  the 
proposed  assessment  criteria.  The  CEP  Team  must  emphasize  that  the 
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following  assessment  applies  to  the  JIIFC  case  study  and  related  activities 
only.  More  importantly,  it  assesses  the  process  as  it  is  applied  to  support 
concept  definition. 


Table  3:  Analysis  of  the  TP4  CEP  Working  Draft  as  Applied  to  JIIFC 


Quality 

Comments 

Relevance 

CapDEM-JIIFC  team  was  able  to  adapt  the  process  to  meet  JIIFC 
requirements. 

Compliance  to 

CapDEM-JIIFC  team  follows  the  IEEE  1220;  DoD  AF  as  foundation 

Standards 

documents  when  interpreting  the  proposed  process. 

Functional  Quality 

With  the  understanding  that  the  proposed  process  is  an  overview,  the 
CapDEM  JIIFC  team  found  this  high-level  guideline  served  as  a  useful 
starting  point.  CEP  Team  has  added  the  context/boundary  definition 
and  Requirements  analysis  in  the  JIIFC  process. 

Technical  Quality 

The  NCEE  toolset  received  a  mixed  review.  DOORS  and  Rational 

Rose  are  both  well-used  and  mature  products.  CORE,  though 
relatively  new,  is  well  received  by  many  systems  engineers  and 
analysts.  Our  technical  team  is  still  struggling  with  Interchange. 
Interchange  is  the  most  significant  piece  in  the  NCEE,  without  which 
the  Integrated  Engineering  Concept  will  be  disabled. 

Effectiveness 

CapDEM  JIIFC  team  was  able  to  follow  the  process  to  develop  the 
“as-is”  integrated  architecture.  CEP  Team  also  applied  IEEE  1220  to 
identify  issues  related  to  requirements  in  the  SOR. 

Efficiency 

To  be  evaluated 

Usability 

Learning  curve  is  not  steep  to  systems  engineers  because  the  process 
does  build  on  general  SysEng  standards  and  strong  common  sense. 
Flowever,  the  CADM  is  relatively  intensive  document  and  the  use  of  it 
still  needs  to  be  assessed. 

Impact 

JIIFC  project  team  has  chosen  to  use  the  JIIFC  process  to  continue 
concept  definition  activities. 

Maturity 

No  known  example.  JIIFC  may  well  be  the  first  one  in  North  America  if 
not  among  the  TTCP  countries. 

Continuity 

To  be  evaluated 

Cost 

To  be  evaluated. 
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6.  Conclusion 


This  report  has  presented  results  of  the  CEP  Team  at  the  end  of  2003.  Since  April 
2003,  the  CEP  Team  has  conducted  many  activities  to  achieve  its  mandate.  Each  team 
members  received  training  on  SysEng  and  TP4  CEP  Working  Draft  and  tools.  A 
practical  and  theoretical  analysis  of  TP4  CEP  Working  Draft  was  performed.  A 
literature  study  covering  SoS,  SBA,  SysEng  standards  and  US  acquisition  was 
conducted. 

Some  perspectives  of  CEP  have  been  investigated.  The  first  perspective  of  CapDEM 
TDP  and  the  TP4  CEP  Working  Draft,  as  described  by  Schmidt,  have  a  good  but  too 
limited  (or  too  concise)  definition  of  a  process  and  CE.  Others  investigations  have 
been  necessary  to  complete  the  understanding  of  CEP.  Possible  scopes  of  the  CE, 
possible  forms  of  the  process  enabling  this  concept  and  specific  objectives  of  the  CE 
have  been  identified.  Finally,  some  candidate  solutions  that  already  applied  to  solving 
similar  problems  have  been  presented/introduced. 

Many  solutions  such  as  concepts,  frameworks,  standards,  processes  and  tools  have 
been  presented/introduced.  They  can  contribute  to  reach  the  CEP  objective.  However, 
most  of  them  are  conceived  in  the  United- States/have  a  US  flavour  and  their  context  of 
use  is  different.  Even  though  all  these  solutions  can  help  to  accomplish  CEP  objective, 
for  some  of  these  technologies,  it  is  hard  to  determine  requirements  behind  them.  Then 
it  is  hard  to  understand  their  strengths  and  weaknesses  and  to  import  only  the  most 
appropriate  elements  in  CEP.  The  solutions  are  difficult  to  compare  and,  thus,  to 
evaluate.  An  important  next  step  will  be  to  evaluate  and  select,  in  part  or  in  totality,  of 
already  working  solutions,  the  creation  of  new  technologies  if  needed  and  the 
integration  of  selected  and  newly  created  solutions  into  a  coherent  and  synchronized 
solution.  For  that  purpose,  overlaps,  gaps  or  inconsistencies  between  them  will  have  to 
be  eliminated.  Even  if  two  solutions  complete  each  other,  their  integration  remains  a 
challenge. 

The  analysis  of  the  TP4  CEP  Working  Draft  has  highlighted  some  main  strengths:  a 
standard  approach,  known  references  and  simulation  usage.  The  process  follows  a 
standard  and  common  sense  approach  similar  to  Enterprise  Architecture  concepts  and 
is  the  combination  of  DoD  Acquisition  Policies.  The  process  requires  the  development 
of  operational  and  physical  models  that  could  be  simulated.  The  main  limitation  is  the 
activity  description.  The  level  of  details  of  each  activity  varies  a  lot;  for  instance,  each 
activity  description  could  include  some  basic  standard  information.  The  TP4  CEP 
Working  Draft  is  built  to  address  the  US  acquisition  problem.  Some  work  is  required 
to  better  understand  the  specificities  of  DND/CF’s  acquisition  process  and  its 
problematic.  The  process  has  its  stand  now  leaves  room  for  interpretation,  is  not  self¬ 
understanding  and  self-applicable.  Considering  these  facts,  the  process  is  not  ready  to 
be  used  and  institutionalized.  On  the  other  hand,  the  TP4  CEP  Working  Draft  general 
approach  being  a  standard  one  provided  very  good  input  to  start  the  development  of 
the  Canadian  CEP. 

The  JIIFC  case  study  provided  a  realistic  setting  for  the  CEP  Team  to  partially 
evaluate  the  TP4  CEP  Working  Draft.  The  JIIFC  use  case  began  in  June  2003.  After 
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the  initial  wave  of  modelling  and  analysis  activities,  a  workshop  was  held  in  October 
2003  to  solicit  feedback  from  the  JIIFC  project  team  on  their  perceived  value  of 
applying  this  process  to  support  JIIFC  concept  definition  phase.  The  project  team 
confirmed  their  strong  acceptance  of  this  CapDEM  approach  through  many 
constructive  comments  throughout  the  workshop. 

The  CEP  Team  has  successfully  achieved  the  goal  of  this  case  study  in  a  5  months 
period.  At  the  end  of  October  2003,  we  were  able  to  evaluate  the  TP4  CEP  Working 
Draft  and  toolsets.  The  CEP  Team  concluded  that  the  TP4  CEP  Working  Draft  served 
adequately  as  a  high-level  guideline  for  the  development  of  the  JIIFC  process. 
Nonetheless,  the  RDA  CHENG  CEE  toolset  has  presented  some  challenges  to  the 
JIIFC  use  case  due  to  the  high  degree  of  customization  required  to  support  projects, 
hence  the  time  required  to  set  up  an  efficient  and  effective  CEE. 

•  The  CEP  Team  has  achieved  the  goal  of  the  JIIFC  case  study  from  June  to  October 
2003. 

•  The  JIIFC  process  should  be  employed  for  the  C4ISR  Campaign  to  provide  more 
effective  context  for  JIIFC. 

•  The  JIIFC  process  should  define  and  support  an  effective  interface  with  the  Project 
Management  Process  to  augment  the  value  added  to  the  decision-making  at  the 
capability  management  level. 

The  JIIFC  process  should  also  define  and  support  an  effective  interface  with  the  M&S 
process  to  facilitate  the  reuse  of  data  to  support  simulation  in  concept  analysis  and 
validation. 


Way  ahead 

This  document  demonstrated  that  the  scope  of  CEP  could  be  very  large.  Many 
questions  remain  to  be  answered  before  defining  completely  the  scope  of  CEP.  Many 
of  them  cannot  be  answered  as  long  as  specific  requirements  of  the  Canadian 
capability  development  community  and  the  identification  of  actual  acquisition 
problems  are  not  known.  Based  on  a  better  understanding  of  the  actual  situation  of  the 
Canadian  acquisition,  the  time  constraints  of  the  TPD  and  the  risks  associated  to 
develop  CEP  for  a  specific  scope,  CEP  Team  will  be  able  to  answer  to  these  questions 
and  to  better  scope  CE.  Finally,  some  questions  will  fall  within  the  competence  of 
stakeholders  to  facilitate  institutionalization  and  resources  prioritization.  Since  the 
problem  space  of  the  CE  is  very  large,  an  initial  solution  should  tackle  only  a  portion 
of  the  problem. 

Based  on  the  knowledge  acquired  during  this  first  nine  months,  the  next  priority  for 
the  CEP  Team  is  to  get  a  very  good  understanding  of  the  current  deficiencies  of  the 
Canadian  process.  As  a  first  step,  the  Canadian  current  situation,  “as-is”,  will  be 
studied,  regarding  mainly  the  current  DND  project  approvals  process.  In  addition, 
other  DND  initiatives  related  to  the  CEP  will  be  examined.  In  parallel,  a  kind  of 
International  current  situation  will  be  worked  out,  looking  at  what  is  being  done 
outside  Canada.  From  these  two  “current  situations”  and  lessons  learned  from  two 
CapDEM  case  studies,  JIIFC  and  ISR  Maritime,  CEP  Version  1,  the  “to-be”  will  be 
elaborated  and  tested  with  potentially  subsets  of  the  case  studies. 
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Annexe  A 


Overview  of  the  Capability  Engineering  Process 

Prepared  for:  TTCP  JSA  TP4 
by  Richard  Schmidt,  Systems  Technology,  Inc,  10  june  2003 


Purpose: 

This  document  provides  an  overview  of  the  Capability  Engineering  Process  based  on 
industry  standards  for  Systems  Engineering.  It  abstracts  the  principles  and  concepts  of 
the  Systems  Engineering  Process  as  it  applies  to  Defense  “System-of-Systems” 
capability  planning  and  engineering.  A  review  of  the  recently  published  DoD 
Directive  5000.1  and  DoD  Instruction  5000.2  is  underway  to  assess  the  compatibility 
of  this  Capability  Engineering  Process  with  the  new  DoD  Acquisition  Guidance. 

1.  Defining  the  Capability  Engineering  Process 

The  Capability  Engineering  Process  bridges  the  Operational  Analysis  activity  and  the 
System  Acquisition  Community  by  analyzing  the  Current  “As-Is”  Integrated 
Architecture  (System-of-System),  establishing  the  Strategic  Vision  for  how  the  war 
fighting  capability  will  be  evolved,  and  developing  the  Transformation  Roadmap  to 
address  Force  Structure  changes,  Evolutionary  Acquisition  Strategy,  and  Force 
Training/Transition  Plan,  and  associated  Investment  Strategy.  The  result  of  this 
process  is  to  provide  a  transformation  roadmap  which  is  achievable,  recognizes  the 
risk  associate  with  the  capability  evolutionary  acquisition  program,  and  how  the  force 
training/transition  will  establish  the  initial  and  full  operational  capability.  Figure  1 
describes  the  Capability  Engineering  Process  which  leads  to  a  System-of-System 
Evolutionary  Acquisition  strategy  for  evolving  Operational  Capabilities  over  a  long¬ 
term  timeframe. 


58 


DRDC  Valcartier  TR  2004-230 


Capability  Engineering  Process 


(Current) 

Architecture 


Capability 

Vision 


Transformation 
Roadmap  — I 


An3 


■portfolio  Investment 
Analysis 


■  “As- Is”  Architecture 

■  “Vision”  Architecture 

■  Transformation  Roadmap 


f  f 

Obsolescence  \  > 

tO  /  m 

£  f 

<D  /  f 

OS  [ 

Capability-Based 

\ 

\  E 

1 

1  r^“" 

System  Acquisition 

o’ 

/  3 

A\V 

Process 

/  ^ 

^  (Conceptual) 

\  £  / 

Final 


ck 


Operational 

Capability 


^  Initial 
Operational 
Capability 


Incremental 
Operational 
Capability 

Figure  2  depicts  how  the  Capability  Engineering  Process  bridges  the  Operational 
Analysis  and  Evolutionary  Acquisition  processes. 


System 
Bloch  1 
flOC) 


System 
Bloch  2 

Interim  Capabilities 


2.  Application  of  the  Systems  Engineering  Process 


DRDC  Valcartier  TR  2004-230 


59 


The  systems  engineering  process  provides  the  framework  for  developing  the  “As-is” 
and  “Vision”  Business  Architectures,  assessing  the  availability  of  systems, 
components  and  technologies  which  can  be  leveraged  to  provide  new  Operational 
capabilities.  The  SysEng  Process  is  applied  iteratively  to: 

a.  Define  the  “As-is”  Integrated  Architecture 

b.  Assess  the  “As-is”  Integrated  Architecture  to  identify  areas  which  can  be 

improved 

c.  Develop  the  Strategic  Vision  to  Guide  Capability  Evolution 

d.  Develop  the  “Vision”  Integrated  Architecture 

e.  Assess  the  costs,  schedule  and  risks  associated  with  implementing  the 

“Vision”  Integrated  Architecture,  and 

f .  Establishing  the  Transformation  Roadmap  for  Acquiring  Systems  or 
modifying  Business  Practices  to  achieve  the  Capability  Objectives 
identified  in  the  Strategic  Vision. 

2.1  Define  the  “As-is”  Integrated  Architecture 

The  “As-is”  Architecture  represents  the  current  Business  Architecture  and  the  inherent 
“capabilities”  this  architecture  provides.  This  Architecture  is  described  in  terms  of 
Organizational  Structure,  roles  &  responsibilities,  Business  Processes,  and  the 
“modernization”  associated  with  the  Organizations  in  terms  of  systems  and 
equipment.  The  Architecture  is  documented  in  an  Operational  Model  (describing  the 
business  processes),  and  the  Physical  Model  (describing  the  Facilities/platforms, 
systems,  interfaces  and  operators). 

2.1.1  Capture  the  “As-is”  Operational  Model 

The  Systems  Engineering  Process  begins  with  understanding  the  customer 
expectations,  identifying  the  Business  Process  and  developing  an  operational  model  of 
the  “As-is”  Architecture.  This  operational  model  identifies  the  organizational 
structure,  the  activities  performed  by  each  element  of  the  organization,  the 
information  exchanged  among  the  participating  organizations,  and  the  resources 
required  to  execute  the  Business  Process. 

Each  of  the  relevant  processes  or  activities  are  decomposed  to  a  level  of  functionality 
which  can  be  associated/allocated  to  humans,  or  systems.  From  this  Operational 
model  the  DOD  Architecture  Framework  Operational  Views  (OVs)  can  be  generated 
except  the  OV-6c  (State  Transition).  In  addition,  some  of  the  System  Views  which 
relate  Operational  Activities  to  System  Functions  can  be  generated. 

2.1.2  Capture  the  “As-is”  Physical  Model 

The  Physical  Model  depicts  the  arrangement  of  existing  facilities/platforms,  systems, 
operators  and  interfaces.  This  establishes  the  linkages  necessary  to  identify  how 
organizational  personnel  utilize  systems  to  execute  the  activities  and  accomplish  the 
business  processes  defined  in  the  Operational  Model.  From  this  Physical  Model  the 
remainder  of  the  DOD  Architecture  Framework  System  Views  (OVs)  can  be 
generated. 
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2.1.3  Identify  the  Measures  of  Effectiveness 

The  Measures  of  Effectiveness  define  how  the  architecture  is  to  be  evaluated  in  terms 
of  performance,  efficiency,  effectiveness,  and  resource  utilization. 

2.1.4  Identify  Areas  of  Opportunity  for  Improvement 

These  measures  provides  the  basis  for  evaluating  the  “As-is”  Architecture  and 
determining  where  opportunities  for  improvement  exists.  This  analysis  provides  the 
information  for  identifying  the  alternatives  available  for  improving  the  Architecture. 
The  Systems  Engineering  Process  establishes  a  generic  approach  for  conducting  trade- 
studies,  assessing  the  risks  and  evaluating  the  cost/benefits  associated  with  each 
alternative. 

2.2  Establish  the  Strategic  Vision 

Based  on  the  evaluation  of  alternatives,  a  strategic  vision  should  be  prepared  which 
addresses  the  long-term  Capability  Objectives  for  improving  the  Architecture  in  terms 
of  Operating  Procedures  (Doctrine  &  Tactics),  Organizational  Realignment,  or 
System  Enhancements/Evolution.  This  activity  must  be  accomplished  concurrently 
with  the  initial  development  of  the  “Vision”  Architecture  to  identify,  evaluate,  and 
select  the  preferred  “Vision”  Architecture  solution. 

This  Strategic  Vision  provides  the  guidelines  for  establishing  the  “Vision” 
Architecture  and  should  address  the  following  topics: 

2.2.1  Evaluate  Availability  of  Technology 

2.2.2  Evaluate  Doctrine  &  Tactic  Evolution 

2.2.3  Evaluate  Force  Structure  Evolution 

2.2.4  Document  the  Strategic  Vision 

Once  the  Alternative  “Vision”  Architectures  have  been  evaluated,  the  preferred 
solution  is  selected  and  the  strategic  vision  is  documented  to  provide  the  long-term 
strategy  for  evolving  the  Business  Architecture.  This  strategic  vision  guides  the 
development  of  the  Transformation  Roadmap  which  establish  the  strategic  “plan”  and 
investment  profile  for  accomplishment  of  the  evolution  of  the  Business  Architecture. 

2.3  Develop  the  "Vision"  Integrated  Architecture 

The  “Vision”  Architecture  represents  the  current  Business  Architecture  and  the 
inherent  “capabilities”  this  architecture  provides.  This  Architecture  is  described  in 
terms  of  Organizational  Structure,  roles  &  responsibilities,  Business  Processes,  and 
the  “modernization”  associated  with  the  Organizations  in  terms  of  systems  and 
equipment.  The  Architecture  is  documented  in  an  Operational  Model  (describing  the 
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business  processes),  and  the  Physical  Model  (describing  the  Facilities/platforms, 
systems,  interfaces  and  operators). 

2.3.1  Identify  Candidate  "Vision”  Architecture  Alternatives 

There  are  always  multiple  approaches  for  improving  the  Business  Processes,  so  the 
various  alternatives  should  be  identified  as  candidates  for  consideration. 

2.3.2  Evaluate  Candidate  Alternatives  for  Feasibility 

The  initial  candidates  should  be  evaluated  to  reduce  the  number  of  alternatives 
selected  for  detailed  evaluation  due  to  feasibility,  costs,  or  performance 
considerations. 

2.3.3  Select  Alternative(s)  for  Concept  Development 

It  may  be  necessary  to  pursue  multiple  alternative  “Vision”  Architectures  to  assess  the 
“Value-added”  with  each  alternative,  and  select  the  best  approach  for  evolving  the 
Business  Architecture.  Initial  Conceptual  Architectures  may  be  developed  to  support 
evaluation. 

2.3.4  Develop  Alternative(s)  Operational  Model 

The  Operational  Model  should  reflect  the  organizational  changes  (force  structure)  and 
process  alterations  desired  to  provide  improved  capabilities.  Each  of  the  relevant 
processes  or  activities  are  decomposed  to  a  level  of  functionality  which  can  be 
associated/allocated  to  humans,  or  systems.  From  this  Operational  model  the  DOD 
Architecture  Framework  Operational  Views  (OVs)  can  be  generated  except  the  OV-6c 
(State  Transition).  In  addition,  some  of  the  System  Views  which  relate  Operational 
Activities  to  System  Functions  can  be  generated. 

2.3.5  Develop  Alternative(s)  Physical  Model 

The  Physical  Model  depicts  the  arrangement  of  legacy  and  new  facilities/platforms, 
systems,  operators  and  interfaces.  This  establishes  the  linkages  necessary  to  identify 
how  organizational  personnel  utilize  systems  to  execute  the  activities  and  accomplish 
the  business  processes  defined  in  the  Operational  Model.  From  this  Physical  Model 
the  remainder  of  the  DOD  Architecture  Framework  System  Views  (OVs)  can  be 
generated. 

2.3.6  Evaluate  Alternative(s)  Architecture  Cost/Effectiveness 

The  Alternative  are  evaluated  to  assess  their  “value-added”  to  the  enterprise,  assess 
risks  to  implementation,  and  provide  a  analytical  basis  for  decision  making. 

2.3.7  Select  &  Document  the  Preferred  Alternative 

The  preferred  solution  is  selected  and  refined  to  resolve  any  outstanding  issues/risks. 
The  architecture  for  the  selected  alternative  is  finalized,  and  document. 

2.4  Establish  the  Transformation  Roadmap 
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The  Transformation  Roadmap  establishes  the  strategic  plan  for  accomplishing  the 
strategic  vision. 

2.4.1  Identify  the  Organizational  (Force)  Structure  Evolution  Plan 

This  section  of  the  Transformation  Roadmap  addresses  the  changes  to  the 
Organizational  structure  and  associated  Roles  and  Responsibilities,  and  the  time  frame 
when  these  changes  are  to  be  implemented. 

2.4.2  Establish  Capability  Evolution  Objectives 

This  section  of  the  Transformation  Roadmap  addresses  the  evolution  of 
Capabilities/Performance  objectives  over  time  with  each  incremental  step  in  evolving 
the  Integrated  Architecture. 

2.4.3  Establish  the  Evolutionary  Acquisition  Roadmap  (Risk  Mitigation) 

This  section  of  the  Transformation  Roadmap  addresses  the  Evolutionary  Acquisition 
Program(s)  which  will  be  established  and  authorized  to  realize  the  Capability 
Objectives  and  Strategic  Vision. 

2.4.4  Establish  the  Force  Training  &  Transition  Plan 

This  section  of  the  Transformation  Roadmap  addresses  the  Force  Readiness  actions 
required  to  train  and  integrate  systems/equipment  items  into  the  operational  forces. 
This  may  include  involving  the  Operational  Forces  in  the  Testing  Programs,  and  the 
establishment  of  the  training  programs  and  associated  systems. 

2.4.5  Establish  the  Investment  Plan 

This  section  of  the  Transformation  Roadmap  addresses  the  Long-term  funding  profile 
for  the  Evolutionary  Acquisition  program(s)  and  should  lead  to  a  stable  funding 
commitment  by  Acquisition  Executive  to  realize  the  Capability  Objectives. 
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